Ubuntu Packaging Guide

Ubuntu Packaging Guide
Release 0.3.3 bzr403 quantal1
Ubuntu Developers
19 de July de 2013
ndice general
1. Artculos 1.1. Introduccin al desarrollo de Ubuntu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Fase de preparacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. Desarrollo distribuido de Ubuntu (Ubuntu Distributed Development, UDD) Introduccin 1.4. Corregir un fallo en Ubuntu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5. Tutorial: corregir un error en Ubuntu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6. Empaquetando nuevo software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7. Actualizaciones de seguridad y de versiones estables . . . . . . . . . . . . . . . . . . . . . . 1.8. Parches a los paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.9. Bibliotecas compartidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.10. Adaptar actualizaciones de software a versiones anteriores . . . . . . . . . . . . . . . . . . . 2. Base de conocimiento 2.1. Comunicacin en el desarrollo de Ubuntu . . . . . . . . . . . . . . . . . 2.2. Descripcin general bsica del Directorio debian/ . . . . . . . . . . . 2.3. autopkgtest: pruebas automticas para paquetes . . . . . . . . . . . . . . 2.4. Obtener el cdigo fuente . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5. Trabajar en un paquete . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6. Buscar revisor y patrocinador . . . . . . . . . . . . . . . . . . . . . . . 2.7. Subir un paquete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8. Obtener lo ltimo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.9. Combinar Actualizar desde Debian y desde aguas arriba (Upstream) 2.10. Usar chroots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.11. Empaquetado tradicional . . . . . . . . . . . . . . . . . . . . . . . . . . 2.12. Empaquetar mdulos y aplicaciones de Python . . . . . . . . . . . . . . 2.13. Empaquetado de KDE . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Lecturas adicionales
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
2 2 4 9 12 15 19 23 25 28 30 32 32 32 38 41 43 44 46 48 49 51 52 53 56 58
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
Ubuntu Packaging Guide, Release 0.3.3 bzr403 quantal1
Le damos la bienvenida a la Gua de empaquetado y desarrollo de Ubuntu. Este es el lugar ocial para aprender sobre el desarrollo y empaquetado en Ubuntu. Despus de leer esta gua, habr: escuchado sobre los actores, procesos y herramientas ms importantes en el desarrollo de Ubuntu, congurado su entorno de desarrollo correctamente, obtenido una mejor idea sobre cmo unirse a nuestra comunidad, corregido un error real como parte de los tutoriales. Ubuntu no solo un sistema operativo libre, gratuito y de cdigo abierto, su plataforma tambin es abierta y est desarrollada de forma transparente. El cdigo fuente para cada uno de los componentes se puede obtener fcilmente y todos los cambios realizados a la plataforma de Ubuntu pueden ser revisados. Esto signica que puede involucrarse activamente en mejorarlo y que la comunidad de desarrolladores de la plataforma de Ubuntu est siempre interesada en ayudar a las personas que comienzan. Ubuntu es adems una comunidad de personas estupendas que creen en el software libre y que ste debera estar accesible para todos. Sus miembros son amigables y quieren que se una. Queremos que se involucre, que realice preguntas, que ayude a hacer Ubuntu mejor junto a nosotros. Si se topa con un problema: no se preocupe! Consulte el artculo sobre comunicacin y sabr cmo puede contactar a otros desarrolladores fcilmente. La gua est separada en dos secciones: Una lista de artculos basados en tareas, cosas que puede desear que se hagan. Un conjunto de artculos de la base de conocimientos que profundizan en partes especicas de las herramientas y ujos de trabajo. Esta gua se centra en el mtodo de empaquetado del desarrollo distribuido de Ubuntu. Es una nueva forma de empaquetado que usa ramas de control de revisiones distribuidas. Actualmente tiene algunas limitaciones lo que signica que muchos equipos de Ubuntu usan mtodos de empaquetado tradicional. Vase la pgina Introduccin a UDD para una introduccin sobre las diferencias.
ndice general
CAPTULO 1
Artculos
1.1 Introduccin al desarrollo de Ubuntu

Ubuntu est formado por miles de componentes distintos, escritos en muchos lenguajes de programacin diferentes. Cada componente, ya sea una biblioteca software, una herramienta o una aplicacin grca, est disponible en forma de paquete fuente. Los paquetes fuente, en la mayora de los casos, constan de dos partes: el cdigo fuente en s, y los metadatos. Los metadatos incluyen las dependencias del paquete, los derechos de autor e informacin sobre la licencia e instrucciones sobre cmo compilar el paquete. Una vez que el paquete est compilado, el proceso de construccin proporciona los paquetes binarios, que son los archivos .deb que el usuario puede instalar. Cada vez que se libera una nueva versin de una aplicacin, o cuando alguien hace cambios al cdigo fuente que va a Ubuntu, el paquete fuente debe ser subido a las mquinas de compilacin de Launchpad para ser compilado. Los paquetes binarios resultantes se distribuyen entonces a los repositorios y sus espejos en distintos pases. Las URLs de /etc/apt/sources.list apuntan a un repositorio o a un espejo. Cada da se crean imgenes para una seleccin de variaciones de Ubuntu. Estas imgenes se pueden usar en varias situaciones. Hay imgenes que se pueden cargar en una llave USB, grabar en DVDs, emplear imgenes para arranque en red e imgenes adecuadas para su telfono o tableta. Ubuntu Desktop, Ubuntu Server, Kubuntu y otros especican una lista de paquetes requeridos que son incluidos en la imagen. Estas imgenes se usan para pruebas de instalacin y proporcionan informacin para la planicacin de emisiones. El desarrollo de Ubuntu depende en gran medida de la fase actual del ciclo de publicacin. Se publica una nueva versin de Ubuntu cada seis meses, lo que solo es posible porque se han establecido fechas estrictas de congelacin. Con cada fecha de congelacin que se va alcanzando, los desarrolladores esperan hacer menos cambios y menos intrusivos. La congelacin de funciones (feature freeze) es la primera gran fecha de congelacin despus de haber pasado la primera mitad del ciclo. En esta fase, las funciones deben estar ya prcticamente implementadas. El resto del ciclo se supone que se centrar en corregir errores. Despus de que la interfaz de usuario, la documentacin, el ncleo, etc. se congelan, se publica una versin beta que pasa gran cantidad de pruebas. De la versin beta en adelante, solo se corrigen errores crticos y se publica la versin candidata, la cual, si no contiene ningn problema serio, es la que se convierte en la versin denitiva.
Miles de los paquetes fuente, miles de millones de lneas de cdigo, cientos de contribuyentes requieren de mucha comunicacin y planicacin para mantener altos estndares de calidad. Al principio y hacia la mitad de cada ciclo de emisin tiene lugar la Ubuntu Developer Summit (cumbre de desarrolladores de Ubuntu) en la que los desarrolladores y contribuyentes se juntan para planicar las caractersticas de las prximas versiones. Cada caracterstica es discutida por sus accionistas y se escribe una especicacin que contiene informacin detallada sobre sus supuestos, implementacin, cambios necesarios en otras partes, cmo probarla y as sucesivamente. Todo esto se hace de forma abierta y transparente, as que puede participar remotamente y escuchar una transmisin de vdeo, chalar con los asistentes y suscribirse a cambios en las especicaciones, de forma que siempre est al da. Sin embargo, no todos los cambios pueden ser discutidos en una reunin, particularmente porque Ubuntu depende de cambios que se hacen en otros proyectos. Es por esto que los contribuyentes se mantienen en contacto permanente. La mayora de los equipos o proyectos usan listas de correo dedicadas para evitar demasiado ruido no relacionado. Para una coordinacin ms inmediata, los desarrolladores y contribuyentes usan charlas en IRC (Internet Relay Chat). Todas las discusiones son abiertas y pblicas. Otra herramienta importante relacionada con la comunicacin son los informes de errores. Siempre que se encuentra un error en un paquete o en un parte de la infraestructura, se rellena un informe de error en Launchpad. Se recoge toda la informacin en dicho informe y se actualiza cuando sea necesario su importancia, estado y desarrollador asignado. Esto lo convierte en una herramienta efectiva para mantenerse al da de los errores de un paquete o proyecto y para organizar la carga de trabajo. La mayora del software disponible a travs de Ubuntu no est escrito por los propios desarrolladores de Ubuntu. La mayora est escrito por otros desarrolladores de otros proyectos de cdigo abierto que luego son integrados en Ubuntu. Estos proyectos se denominan upstreams (aguas arriba), porque su cdigo fuente uye a Ubuntu, donde simplemente se integra. La relacin con los proyectos upstream tiene una importancia crtica para Ubuntu. No es solo cdigo lo que Ubuntu recoge aguas arriba, sino que los proyectos upstream obtienen tambin usuarios, informes de error y parches de Ubuntu (y de otras distribuciones). El proyecto upstream ms importante para Ubuntu es Debian. Debian es la distribucin en la que se basa Ubuntu y muchas de las decisiones de diseo relativas a la infraestructura de empaquetado se hacen all. Traicionalmente, Debian ha tenido siempre mantenedores dedicados para cada paquete individual o equipos dedicados de mantenimiento. En Ubuntu hay equipos que tienen inters en un subconjunto de paquetes tambin y, naturalmente, cada desarrollador tiene un rea de especializacin, pero la participacin (y permisos de subida) est generalmente abierta a cualquiera que demuestre capacidad y voluntad. Conseguir un cambio en Ubuntu como un nuevo contribuyente no es tan desalentador como parece y puede resultar una experiencia muy graticante. No se trata nicamente de aprender algo nuevo y excitante, sino tambin de compartir la solucin y resolver un problema para millones de otros usuarios. Los desarrollos de cdigo abierto se producen en un mundo distribuido con distintos objetivos diferentes y con reas de inters diferentes. Por ejemplo, podra darse el caso de que alguien aguas arriba (upstream) est interesado en trabajar en una nueva funcionalidad importante mientras que Ubuntu, debido a su estricta planicacin de emisiones, est interesado en distribuir una versin slida solo con algunas correcciones de errores. Es por ello que se usa el desarrollo distribuido, en el que se trabaja en distintas ramas de cdigo que son combinadas con las dems despus
1.1. Introduccin al desarrollo de Ubuntu
de revisiones de cdigo y sucientes discusiones.
En el ejemplo mencionado anteriormente tendra sentido emitir Ubuntu con una versin existente del proyecto, aadir la correccin del error, integrarla aguas arriba (upstream) para su prxima emisin y distribuirla (si fuera conveniente) en la prxima emisin de Ubuntu. Sera el mejor compromiso posible y una situacin en la que todo el mundo gana. Para arreglar un error en Ubuntu, primero debera obtener el cdigo fuente del paquete, despus trabajar en la solucin, documentarla de forma que sea fcil de entender por otros desarrolladores y usuarios y luego compilar el paquete para probarlo. Una vez lo haya probado, puede proponer fcilmente que el cambio se incluya en la publicacin actualmente en desarrollo de Ubuntu. Un desarrollador con permisos para subir el cdigo lo revisar y har que se integre en Ubuntu.
Cuando intente encontrar una solucin, habitualmente es una buena idea comprobar los proyectos aguas arriba (upstreams) para ver si el problema (o una posible solucin) es conocido y, si no, hacer lo posible para que la solucin sea un esfuerzo concertado. Podran ser necesarios pasos adicionales para hacer que el cambio se incluya en una versin antigua, aunque todava soportada de Ubuntu, y enviarlo aguas arriba (upstream). Los requisitos ms importantes para tener xito en el desarrollo de Ubuntu son: tener una habilidad especial para hacer que las cosas funcionen de nuevo, no tener miedo a leer documentacin y a hacer preguntas, ser un jugador de equipo y disfrutar con algo de trabajo detectivesco. Algunos buenos sitios en los que hacer preguntas son ubuntu-motu@lists.ubuntu.com y #ubuntu-motu en irc.freenode.net. Encontrar fcilmente un montn de nuevos amigos y personas con la misma pasin que usted: hacer del mundo un lugar mejor haciendo mejor software de cdigo abierto.
1.2 Fase de preparacin

Hay una serie de cosas que necesita hacer para poder empezar a desarrollar para Ubuntu. Este artculo est diseado para que pueda congurar su equipo de forma que pueda comenzar a trabajar con paquetes y subirlos a Launchpad, la plataforma de hospedaje de Ubuntu. Los temas cubiertos son: Instalar software relacionado con el empaquetado. Incluye: Utilidades de empaquetado especcas de Ubuntu Software de cifrado, para poder vericar que el trabajo se hizo por el usuario indicado
1.2. Fase de preparacin
Software de cifrado adicional para poder enviar archivos de forma segura Crear y congurar una cuenta en Launchpad Congurar un entorno de desarrollo para ayudarle compilar paquetes localmente, interactuar con otros desarrolladores y proponer sus cambios en Launchpad. Nota: Se recomienda hacer el trabajo de empaquetado usando la versin actual en desarrollo de Ubuntu. Esto le permitir probar los cambios en el mismo entorno en el que sern realmente aplicados y usados. No se preocupe, sin embargo, la pgina Ubuntu development release wiki page muestra varias formas de usar de forma segura la versin de desarrollo.
1.2.1 Instalar software bsico de empaquetado

Existen varias herramientas que le harn su vida de desarrollador de Ubuntu mucho ms fcil. Encontrar estas herramientas ms adelante en esta misma gua. Para instalar la mayora de las herramientas necesitar ejecutar esta orden:
$ sudo apt-get install gnupg pbuilder ubuntu-dev-tools bzr-builddeb apt-file
Nota: desde Ubuntu 11.10 Oneiric Ocelot (o si tiene activa las actualizaciones no soportadas en una versin actualmente soportada), el siguiente comando instalar las herramientas anteriores y otras que son bastante habituales en el desarrollo de Ubuntu:
$ sudo apt-get install packaging-dev
Esta orden instalar el software siguiente: gnupg GNU Privacy Guard contiene herramientas que necesitar para crear una clave criptogrca con la que rmar los archivos que quiera subir a Launchpad. pbuilder una herramienta para realizar compilaciones reproducibles de una paquete en un entorno limpio y aislado. ubuntu-dev-tools (y devscripts, una dependencia directa) una coleccin de herramientas que hace muchas tareas del empaquetado ms sencillas. bzr-builddeb (y bzr, una dependencia) sistema de control de versiones distribuido con Bazaar, una nueva forma de trabajar con paquetes para Ubuntu que facilitar a muchos desarrolladores colaborar y trabajar sobre el mismo cdigo, haciendo que resulte sencillo combinar el trabajo de los dems. apt-file proporciona una forma sencilla de encontrar el paquete binario que contiene un archivo determinado. Crear su clave GPG GPG viene de GNU Privacy Guard (guardian de privacidad de GNU) e implementa el estndar OpenPGP que le permite rmar y cifrar mensajes y archivos. Es til para varios propsitos. En nuestro caso es importante que pueda rmar archivos con su clave de forma que puedan identicarse como algo en lo que usted ha trabajado. Si sube un paquete fuente a Launchad, solo lo aceptar si puede determinar absolutamente quin lo ha subido. Para generar una nueva clave GPG, ejecute:
$ gpg --gen-key
GPG primero le preguntar qu tipo de clave desea generar. Elegir el tipo por defecto (RSA y DSA) es correcto. Despus le preguntar por el tamao de la clave. El predeterminado (actualmente 2048) es adecuado, pero 4096 es
ms seguro. Posteriormente le preguntar si desea que la clave caduque en algn momento. Es seguro decir 0, lo que signica que nunca expirar. Las ltimas preguntas sern sobre su nombre y direccin de correo electrnico. Aqu simplemente elija los que quiere usar para el desarrollo de Ubuntu, y puede aadir direcciones de correo electrnico adicionales posteriormente. No es necesario aadir un comentario. Luego tendr que establecer una frase de paso, elija una segura (una frase de paso es simplemente una contrasea en la que se permite la inclusin de espacios). Ahora GPG crear la clave, lo que le puede llevar un tiempo; necesita algunos bytes aleatorios, as que si le da al sistema algn trabajado para hacer, mejor. Mueva el cursor, escriba algunos prrafos de texto aleatorio o cargue alguna pgina web. Una vez hecho esto, recibir un mensaje similar a:
pub uid sub 4096R/43CDE61D 2010-12-06 Key fingerprint = 5C28 0144 FB08 91C0 2CF3 37AC 6F0B F90F 43CD E61D Daniel Holbach <dh@mailempfang.de> 4096R/51FBE68C 2010-12-06
En este caso 43CDE61D es el ID de clave. Despus necesitar cargar la parte pblica de su clave a un servidor de claves, de forma que el resto del mundo pueda identicar los mensajes y archivos como suyos. Para hacerlo, escriba:
$ gpg --send-keys --keyserver keyserver.ubuntu.com <KEY ID>
Esto mandar su clave al servidor de claves de Ubuntu, pero una red de servidores de claves la sincronizarn automticamente entre ellos. Una vez que se complete esta sincronizacin, su clave pblica rmada estar lista para vericar sus contribuciones por todo el mundo. Crear su clave SSH SSH viene de Secure Shell (intrprete de rdenes seguro) y es un protocolo que le permite intercambiar datos de una forma segura en una red. Es habitual usar SSH para acceder a un intrprete de rdenes en otro equipo y usarlo para transferir archivos de forma segura. Para nuestros propsitos, usaremos SSH bsicamente para subir paquetes fuentes a Launchpad. Para generar una clave SSH, escriba:
$ ssh-keygen -t rsa
El nombre de archivo por defecto normalmente tiene sentido, as que puede dejarlo tal cual. Por motivos de seguridad, se recomienda encarecidamente que use una frase de paso. Congurar pbuilder pbuilder le permite compilar paquetes localmente en su equipo. Sirve para un par de propsitos: La compilacin se har en un entorno mnimo y limpio. Esto le ayuda a asegurarse de que sus compilaciones se completan de una forma reproducible, pero sin modicar su sistema local. No es necesario instalar todas las dependencias de compilacin necesarias de forma local. Puede congurar varias instancias para distintas versiones de Ubuntu y Debian. Congurar pbuilder es muy fcil, ejecute:
$ pbuilder-dist <release> create
donde <versin> es, por ejemplo, natty, maverick, lucid o, en el caso de Debian, quiz sid. Le llevar un rato ya que descargar todos los paquetes necesarios para una instalacin mnima. Sin embargo, estos paquetes sern cacheados.
1.2.2 Preparar una conguracin para trabajar con Launchpad

Con una conguracin local bsica establecida, el siguiente paso ser congurar el sistema para trabajar con Launchpad. Esta seccin se centrar en los siguientes temas: Qu es Launchpad y la creacin de una cuenta de Launchpad Subir claves GPG y SSH a Launchpad Congurar Bazaar para trabajar con Launchpad Congurar Bash para trabajar con Bazaar Acerca de Launchpad Launchpad es la pieza central de la infraestructura usada en Ubuntu. No slo almacena todos sus paquetes y cdigo, sino tambin cosas tales como traducciones, informes de errores e informacin sobre la gente que trabaja en Ubuntu y su pertenencia a equipos. Tambin usar Launchpad para publicar sus propuestas de solucin y hacer que otros desarrolladores de Ubuntu las revisen y esponsoricen. Necesitar registrarse en Launchpad y proporcionar una cantidad mnima de informacin. Esto le permitir descargar y subir cdigo, enviar informes de error y ms cosas. Adems de hospedar a Ubuntu, Launchpad puede hospedar a cualquier otro proyecto de software libre. Para ms informacin vase la Launchpad Help wiki. Obtener una cuenta de Launchpad Si no tiene todava una cuenta de Launchpad, puede fcilmente create one. Si tiene una cuenta de Launchpad pero no puede recordar su identicador de Launchpad, puede encontrarlo visitando https://launchpad.net/~ y mirando en la parte que sigue al smbolo ~ en la URL. El proceso de registro de Launchpad le pedir que elija un nombre de usuario. Se recomienda que use su nombre real de forma que los colegas desarrolladores de Ubuntu lleguen a conocerle mejor. Cuando registre una nueva cuenta, Launchpad le enviar un correo con un enlace que deber abrir en su navegador para vericar su direccin de correo electrnico. Si no lo recibe, compruebe su carpeta de correo no deseado (spam). The new account help page en Launchpad contiene ms informacin sobre el proceso y parmetros adicionales que puede cambiar. Subir su clave GPG a Launchpad Para buscar su huella de GPG, ejecute:
$ gpg --fingerprint <email@address.com>
y le mostrar algo como:

pub uid sub 4096R/43CDE61D 2010-12-06 Key fingerprint = 5C28 0144 FB08 91C0 2CF3 37AC 6F0B F90F 43CD E61D Daniel Holbach <dh@mailempfang.de> 4096R/51FBE68C 2010-12-06
Dirjase a https://launchpad.net/~/+editpgpkeys y copie la huella de la clave (Key ngerprint) en la casilla de texto. En el caso anterior sera 5C28 0144 FB08 91C0 2CF3 37AC 6F0B F90F 43CD E61D. Ahora pulse en Import Key (importar clave).
Launchpad usar la huella para comprobar su clave en el servidor de claves de Ubuntu. Si tiene xito, le enviar un correo electrnico cifrado, pidindole que conrme la clave importada. Compruebe su cuenta de correo electrnico y lea el mensaje que le ha enviado Launchpad. Si su cliente de correo electrnico soporta el cifrado de OpenPGP, le pedir la contrasea que eligi para la clave cuando la gener GPG. Escriba la contrasea, y luego pulse en el enlace que conrma que esa clave es suya. Launchpad cifra el mensaje de correo usando su clave pblica, para asegurar que la clave es suya. Si utiliza Thunderbird, el cliente de correo electrnico predeterminado en Ubuntu, puede instalar el complemento Enigmail para descifrar el mensaje fcilmente. Si su software de correo electrnico no es compatible con el cifrado OpenPGP, copie el contenido del mensaje cifrado, escriba gpg en su terminal, y pegue el contenido del mensaje en la ventana de la terminal. De vuelta a la web de Launchpad, use el botn Conrm (conrmar) y Launchpad completar la importacin de su clave OpenPGP. Encuentre ms informacin en https://help.launchpad.net/YourAccount/ImportingYourPGPKey Subir su clave SSH a Launchpad Abra https://launchpad.net/~/+editsshkeys en su navegador web y abra tambin ~/.ssh/id_rsa.pub en un editor de textos. Esta es la parte pblica de su clave SSH, as que es seguro compartirla en Launchpad. Copie el contenido del archivo y pguelo en la casilla de texto de la pgina web que dice Add an SSH key (aadir una clave SSH). Ahora pulse Import Public Key (importar clave pblica). Para ms informacin sobre este proceso, visite la pgina creating an SSH keypair en Launchpad. Congurar Bazaar Bazaar es la herramienta que se usa para almacenar cambios en el cdigo de una manera lgica, para intercambiar los cambios propuestos y para combinarlos, incluso si el desarrollo se realiza de forma concurrente. Se usa para el nuevo mtodo de desarrollo distribuido de Ubuntu para trabajar con paquetes de Ubuntu. Para decirle a Bazaar quin es usted, simplemente ejecute:
$ bzr whoami "Bob Dobbs <subgenius@example.com>" $ bzr launchpad-login subgenius
whoami le dir a Bazaar qu nombre y direccin de correo electrnico debera usar para enviarle mensajes. Con launchpad-login establece su ID de Launchpad. De esta forma el cdigo que publique en Launchpad se asociar a usted. Nota: si no puede recordar el ID, visite https://launchpad.net/~ y mire a dnde le redirecciona. La parte tras el smbolo ~ en la URL es su ID de Launchpad. Congurar el intrprete de rdenes De forma similar a Bazaar, las herramientas de empaquetado de Debian/Ubuntu necesitan conocerle. Simplemente abra su ~/.bashrc en un editor de textos y aada lo siguiente al nal del mismo:
export DEBFULLNAME="Bob Dobbs" export DEBEMAIL="subgenius@example.com"
Ahora guarde el archivo y reinicie su terminal o ejecute:

$ source ~/.bashrc
(si no usa el intrprete de rdenes por defecto, que es bash, edite el archivo de conguracin de dicho intrprete como corresponda).
1.3 Desarrollo distribuido de Ubuntu (Ubuntu Distributed Development, UDD) Introduccin

Esta gua se centra en el empaquetado usando el mtodo de desarrollo distribuido de Ubuntu (UDD). El desarrollo distribuido de Ubuntu (UDD) es una nueva tcnica para desarrollar paquetes de Ubuntu que usan herramientas, procesos y ujos de trabajos similares a desarrollos de software basados en sistemas de control de versiones distribuidos (DVCS) genricos.
1.3.1 Limitaciones del empaquetado tradicional

Tradicionalmente los paquetes de Ubuntu se han mantenido en archivos comprimidos tar. Un paquete fuente tradicional se compone del tar fuente de aguas arriba, un tar de debian (o archivo diff comprimido para paquetes ms antiguos) que contiene el empaquetado y un archivo .dsc de metadatos. Para ver un paquete tradicional ejecute:
$ apt-get source kdetoys
Esto descargar el fuente de aguas arriba kdetoys_4.6.5.orig.tar.bz2, el empaquetado kdetoys_4.6.5-0ubuntu1.debian.tar.gz y los metadatos kdetoys_4.6.5-0ubuntu1~ppa1.dsc. Suponiendo que tiene instalado dpkg-dev los extraer y le proporcionar el paquete fuente. En empaquetado tradicional editara esos archivos y los subira. Sin embargo, esto le limita las oportunidades de colaborar con otros desarrolladores, los cambios deben ser pasados como archivos diff sin que exista un lugar centralizado en el que rastrearlos y dos desarrolladores no pueden hacer cambios al mismo tiempo. As que la mayora de los equipos han puesto sus empaquetados en un sistema de control de versiones. Esto facilita mucho que varios desarrolladores puedan trabajar juntos en el mismo paquete. Sin embargo, no hay una conexin directa entre el sistema de control de versiones y el repositorio de paquetes, as que ambos deben mantenerse sincronizados manualmente. Puesto que cada equipo trabaja en su propio sistema de control de versiones un futuro desarrollador debe primero averiguar dnde se encuentra y cmo obtener el empaquetado antes de que pueda trabajar en el paquete.
1.3.2 Desarrollo distribuido de Ubuntu

Con el desarrollo distribuido de Ubuntu todos los paquetes del repositorio de Ubuntu (y de Debian) se importan automticamente en ramas Bazaar en el sitio de hospedaje de cdigo Launchpad. Los cambios se pueden hacer directamente en eses ramas en pasos incrementales y por cualquiera con permisos para conrmar. Los cambios tambin se pueden hacer en ramas bifurcadas y vueltas a fusionar con propuestas de integracin (merge proposals) cuando son lo sucientemente grandes para necesitar una revisin o si estn realizadas por alguien que no tiene permiso de conrmar directamente. Las ramas UDD estn todas en una ubicacin estndar, as que hacer una extraccin es sencillo:
$ bzr branch ubuntu:kdetoys
El historial de fusiones incluye dos ramas separadas, una para el fuente de aguas arriba y otra que aade el directorio de empaquetado debian/:
$ cd kdetoys $ bzr qlog
1.3. Desarrollo distribuido de Ubuntu (Ubuntu Distributed Development, UDD) Introduccin 9
(esta orden usa qbzr como IGU, ejecute log en lugar de qlog para una salida por consola).
Esta rama UDD de kdetoys muestra el empaquetado completo para cada versin subida a Ubuntu con crculos grises y las versiones fuentes de aguas arriba con crculos verdes. Las versiones se etiquetan o con la versin de Ubuntu como 4:4.2.29-0ubuntu1 o para las ramas de aguas arriba, con su versin, como upstream-4.2.96. Muchos paquetes de Ubuntu se basan en paquetes de Debian, UDD tambin importa el paquete de Debian en nuestras ramas. En la rama kdetoys anterior las versiones Debian de unstable vienen de la fusin con los crculos azules, mientras que las de Debian experimental vienen de fusiones con los crculos amarillos. Las versiones de Debian estn etiquetadas con su nmero de versin, por ejemplo, 4:4.2.2-1. As que desde una rama UDD puede ver el historial completo de cambios del paquete y comparar dos versiones cualesquiera. Por ejemplo, para ver los cambios entre la versin 4.2.2 en Debian y la 4.2.2 en Ubuntu use:
$ bzr qdiff -r tag:4:4.2.2-1..tag:4:4.2.2-1ubuntu1
(esta orden usa qbzr como IGU, ejecute diff en lugar de qdiff para una salida por consola).
Con esto podemos ver claramente qu ha cambiado en Ubuntu comparado con Debian, lo que es muy til.
1.3.3 Bazaar
Las ramas UDD usan Bazaar, como sistema de control de versiones distribuido pensado para ser fcil de usar para gente familiarizada con otros sistemas populares como Subversion, pero ofreciendo la potencia de Git. Para empaquetar con UDD necesitar tener nociones bsicas de Bazaar para gestionar archivos. Como introduccin a Bazaar consulte el tutorial de cinco minutos de Bazaar y la gua de usuario de BazaarBazaar Five Minute Tutorial Bazaar Users Guide.
1.3.4 Limitaciones del UDD

El desarrollo distribuido de Ubuntu es un nuevo mtodo para trabajar con paquetes de Ubuntu. Actualmente tiene algunas limitaciones importantes: Realizar una bifurcacin completa con historial puede suponer mucho tiempo y recursos d ered. Puede resultar ms rpido realizar una extraccin ligera bzr checkout --lightweight ubuntu:kdetoys pero esto necesitar de acceso a la red para cualquier operacin de bzr posterior. Trabajar con parches es engorroso. Los parches se pueden considerar como un sistema de control de versiones bifucardo, as que se termina con un RCS sobre otro RCS. No hay manera de construir directamente desde las ramas. Necesita crear un paquete fuente y subirlo. Algunos paquetes no se han importado con xito en ramas UDD. Las versiones recientes de Bazaar noticarn automticamente cuando se d este caso. Tambin puede comprobar manualmente el estado del importador de paquetes status of the package importer antes de trabajar en una rama. Se est trabajando en todo lo anterior y se espera que UDD se convierta en la principal forma de trabajar en paquetes de Ubuntu prximamente. Sin embargo, actualmente la mayora de los equipos dentro de Ubuntu todava no trabajan con ramas UUD para sus desarrollos. Puesto que las ramas UDD son lo mismos que los paquetes en el repositorio todos los equipos deberan ser capaces de aceptar fusiones contra ellas.
1.4 Corregir un fallo en Ubuntu

1.4.1 Introduccin
Si se han seguido las instrucciones de ponerse en marcha con el desarrollo de Ubuntu, debera estar preparado para comenzar.
Como se puede observar en la imagen superior, no hay sorpresas en el proceso de correccin de fallos en Ubuntu: se encuentra un problema, se descarga el cdigo fuente, se trabaja en la solucin, se prueba, se envan los cambios a Launchpad y se pide que sea revisado e integrado. Durante esta gua se pasar por todos estos pasos, uno a uno.
1.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 solucin), 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, pequeos errores denominados de bocado (bitesize) y otros. Comprubelo y encuentre su primer error en el que trabajar.
1.4.3 Averiguar qu se debe corregir

Si no se conoce el paquete fuente que contiene el cdigo 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 aplicacin de escritorio para tomar notas. Tomboy se puede iniciar ejecutando con /usr/bin/tomboy desde la lnea de rdenes. Para conocer el paquete binario al que pertenece esta aplicacin, 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 comn 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
1.4. Corregir un fallo en Ubuntu
12
$ apt-cache showsrc python-vigra | grep ^Package: Package: libvigraimpex
apt-cache es parte de la instalacin estndar de Ubuntu.
1.4.4 Obtener el cdigo

Una vez que sabe el paquete fuente en el que trabajar, querr obtener una copia del cdigo 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 solucin y subir su propuesta de solucin a Launchpad, en forma de rama de Bazaar. Cuando est satisfecho con la solucin, puede submit a merge proposal enviar una propuesta de fusin, mediante la cual solicita a otros desarrolladores de Ubuntu que revisen y aprueben sus cambios. Si ellos estn de acuerdo con los cambios, uno de los desdarrolladores de Ubuntu subir la nueva versin del paquete a Ubuntu de forma que todoas se puedan beneciar de su excelente solucin obteniendo por ello algo de crdito. Est ahora en camino de convertirse un desarrollador de Ubuntu! En las siguientes secciones se describe en detalle cmo bifurcar el cdigo, subir la correccin y solicitar una revisin.
1.4.5 Trabajar en una solucin

Se han escrito libros completos sobre cmo encontrar errores, cmo arreglarlos, cmo probarlos, etc. Si completamente novato en programacin, 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 solucin, asegrese de investigar si alguien ms ya lo ha solucionado o est trabajando en una solucin. 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 versin ms reciente) podra 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 solucin. La orden edit-patch es una forma simple de aadir 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 edicin escriba exit o pulse Ctrl+D para abandonar el intrprete de rdenes temporal. El nuevo parche se habr aadido a debian/patches.
1.4.6 Probar la solucin

Para crear un paquete de prueba con los cambios, ejecute estas rdenes:
$ bzr builddeb -- -S -us -uc $ pbuilder-dist <release> build ../<package>_<version>.dsc
13
Esto crear un paquete fuente a partir de los contenidos de la rama (-us -uc simplemente omitir el paso de la rma de los paquetes fuente) y pbuilder-dist construir el paquete a partir del fuente para la release (versin) que haya elegido. Cuando la compilacin concluya con xito, instale el paquete desde ~/pbuilder/<release>_result/ (use sudo dpkg -i <paquete>_<versin>.deb). Compruebe entonces si se ha corregido el error. Documentar la solucin Es muy importante documentar con suciente detalle los cambios que se hacen, de tal forma que los desarrolladores que revisen el cdigo 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 ms fcil de actualizar esto es ejecutar:
$ dch -i
Esto aadir una entrada modelo al registro de cambios y lanzar un editor en el que poder rellenar los campos vacos. Un ejemplo podra ser:
specialpackage (1.2-3ubuntu4) natty; 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 debera rellenar por usted la primera y ltima lnea de la entrada en el registro de cambios. La lnea 1 contiene el nombre del paquete fuente, la nmero de versin, la emisin de Ubuntu a la que va dirigida, la urgencia (que casi en todos los casos es low, baja). La ltima lnea siempre contiene el nombre, la direccin de correo y la fecha y hora (en formato RFC 5322) del cambio. Realizado todo esto, cntrese en la propia entrada del registro de cambios: es muy importante documentar: 1. dnde se hizo el cambio 2. qu se ha cambiado 3. dnde ocurri la discusin acerca del cambio En este (muy sencillo) ejemplo el ltimo punto se cubre por (LP: #123456) que se reere al reporte 123456 en Launchpad. Los reportes de errores, discusiones en listas de correos y documentos de especicaciones son buenas fuentes de informacin que justican las razones por las cuales se hacen los cambios. Como ventaja adicional, si se usa la notacin LP: #<nmero> para de los errores de Launchpad, dichos errores se cerrarn automticamente cuando los cambios se suban a Ubuntu. Aplicar la solucin Con la entrada del registro de cambios escrita y guardada, puede ejecutar simplemente:
debcommit
y se aplicarn los cambios (localmente) con la entrada del archivo registro de cambios como mensaje de la conrmacin. 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>
14
Un ejemplo podra ser:

lp:~emmaadams/ubuntu/natty/specialpackage/fix-for-123456
As, si ejecuta:
bzr push lp:~emmaadams/ubuntu/natty/specialpackage/fix-for-123456 bzr lp-propose
habr nalizado el proceso. La orden push enva los cambios a Launchpad y la segunda orden abre la pgina de Launchpad en la rama remota en su navegador. Localice ah en enlace (+) Propose for merging, plselo para que se revise el cambio por algn desarrollador y se incluya en Ubuntu. Nuestro artculo sobre seeking sponsorship entra en ms detalle sobre cmo obtener respuesta a los cambios propuestos. Si su rama correge incidencias en versiones estables o es una correccin de seguridad, es posible que le interese echar un vistazo al artculo Security and stable release updates.
1.5 Tutorial: corregir un error en Ubuntu

Aunque los mecanismos para corregir un error (xing a bug) son los mismos para cada error, cada problema al que se enfrente es probable que sea distinto de los dems. Un ejemplo de un problema concreto le podra ayudar a formar una idea de lo que tener en cuenta de forma general. Nota: En el momento de escribir este artculo esto no haba sido corregido todava, aunque es posible que para cuando est leyndolo ya se haya solucionado. Tmelo como un ejemplo e intente adaptarlo al problema concreto que est afrontando.
1.5.1 Conrmar el problema

Digamos que el paquete bumprace no tiene una pgina web en su descripcin. Como primer paso podra comprobar que el problema no est ya resuelto. Es fcil de hacer, bien mirando al Centro de software o ejecutando:
apt-cache show bumprace
La salida debera ser algo parecido a esto:

Package: bumprace Priority: optional Section: universe/games Installed-Size: 136 Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com> 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
1.5. Tutorial: corregir un error en Ubuntu
15
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 sera gedit, el cual tiene denida una pgina 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 investigacin.
1.5.2 Investigar la situacin de un error

Primero debera comprobar si ya existe un informe de error para el problema en Ubuntu. Quiz ya haya alguien trabajando en una correccin o podamos contribuir de alguna forma a la solucin. Para Ubuntu echamos un vistazo rpido 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 debera llevar la pgina de error del paquete fuente en cuestin. Para Debian, que es la fuente principal de paquetes para Ubuntu, echamos un vistazo http://bugs.debian.org/src:bumprace y tampoco pudimos encontrar un informe de error sobre nuestro problema. a
Nota: Para Debian la URL http://bugs.debian.org/src:<package> siempre debera llevar la pgina de error del paquete fuente en cuestin. El problema en el que estamos trabajando es especial ya que slo afecta a parte relacionada con el empaquetado de bumprace. Si hubiera un problema en el cdigo fuente sera til comprobar tambin 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 mayora de los casos debera encontrarlo fcilmente.
1.5.3 Ofrecer ayuda

Si encuentra un error abierto que no est asignado a nadie y est en situacin de corregirlo, debera aadir un comentario con su solucin. Asegrese de incluir tanta informacin como sea posible: bajo qu circunstancias ocurre el error? cmo ha corregido el problema? ha probado la solucin? Si no se ha rellenado ningn informe de error, puede crear uno. Lo que debe tener en cuenta es lo siguiente: es la incidencia tan pequea que simplemente pedir que alguien la conrme es suciente? 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.
16
1.5.4 Corregir la incidencia

Para este ejemplo concreto es suciente con buscar en la web bumprace y encontrar su pgina web. asegrese de que es un sitio que est vivo y no solo un catlogo de software. http://www.linux-games.com/bumprace/ tiene pinta de ser el lugar apropiado. Para afrontar la incidencia en el paquete fuente, necesitamos antes el cdigo fuente, que puede ser obtenido fcilmente ejecuntando:
bzr branch ubuntu:bumprace
Si ha ledo antes sobre la visin general del directorio de Debian (the Debian Directory Overview), podra recordar que la pgina web para un paquete se indica en la primera parte del archivo debian/control, la seccin que comienza con Source:. As que lo siguiente que hacemos es ejecutar:
cd bumprace
y editar debian/control para aadir Homepage: http://www.linux-games.com/bumprace/. Al nal de la primera seccin debera ser un buen lugar. Una vez que lo haya hecho, guarde el archivo. Si ahora ejecuta:
bzr diff
debera ver algo como esto:

=== modified file debian/control --- debian/control 2012-05-14 23:38:14 +0000 +++ debian/control 2012-09-03 15:45:30 +0000 @@ -12,6 +12,7 @@ libtool, zlib1g-dev Standards-Version: 3.9.3 +Homepage: http://www.linux-games.com/bumprace/ Package: bumprace Architecture: any
Este diff es bastante simple de comprender. El + indica una lnea que ha sido aadida. En nuestros caso se ha aadido justo antes de la segunda seccin, comenzado con Package, lo que indica un paquete binario resultante.
1.5.5 Documentar la solucin

Es importante explicar a sus compaeros desarrolladores lo que hizo exactamente. Si ejecuta:
dch -i
esto iniciar un editor con una entrada modelo del registro de cambios (changelog) que solo tiene que rellenar. En nuestro caso bastara algo como debian/control: Added projects homepage. (debian/control: aadida pgina web del proyecto). A continuacin guarde el archivo. Para comprobar nuevamente que ha funcionado, ejecute:
bzr diff debian/changelog
y ver algo como esto:
17
=== modified file debian/changelog --- debian/changelog 2012-05-14 23:38:14 +0000 +++ debian/changelog 2012-09-03 15:53:52 +0000 @@ -1,3 +1,9 @@ +bumprace (1.5.4-1ubuntu1) UNRELEASED; urgency=low + + * debian/control: Added projects homepage. + + -- Peggy Sue <peggy.sue@example.com> Mon, 03 Sep 2012 17:53:12 +0200 + bumprace (1.5.4-1) unstable; urgency=low * new upstream version, sound and music have been removed (closes: #613344)
Algunas consideraciones adicionales: Si tiene una referencia a un error en Launchpad que ha sido corregido por la incidencia, aada (LP: #<bug number>) a la lnea de entrada del changelog, por ejemplo (LP: #123456). Si quiere hacer que su correccin se incluya en Debian, la sintaxis para un bug de Debian es (Closes: #<bug number>), por ejemplo: (Closes: #123456). Si es una referencia a un error aguas arriba o de Debian o a una discusin en una lista de correo, mencinelo tambin. Intente cortar las lneas a 80 caracteres. Intente ser especco, no es un ensayo, pero describa lo suciente para que cualquiera (que no haya mirando la incidencia en detalle) pueda comprenderlo. Mencione cmo y dnde corrigi la incidencia.
1.5.6 Probar la solucin

Para probar la correccin necesita congurar su entorno de desarrollo (have your development environment set up), luego compilar el paquete, instalarlo y vericar que se ha solucionado el problema. En nuestro caso sera:
bzr bd -- -S pbuilder-dist <current Ubuntu release> build ../bumprace_*.dsc dpkg -I ~/pbuilder/*_result/bumprace_*.deb
En el primer paso compilamos el paquete fuente desde la rama, y luego lo compilamos usando pbuilder, luego inspeccionamos el paquete resultante para comprobar si el campo Homepage (pgina web) se ha aadido correctamente. Nota: En muchos casos tendr que instalar de verdad el paquete para asegurarse de que funciona como se espera. En nuestro caso es mucho ms fcil. Si la compilacin tuvo xito, encontrar los paquetes binarios en ~/pbuilder/<release>_result. Instlelos mediante sudo dpkg -i <package>.deb o haciendo doble clic sobre ellos en el administrador de archivos. Como hemos vericado, el problema est resuelto, as que el siguiente paso es compartir nuestra solucin con el resto del mundo.
18
1.5.7 Conseguir que se incluya la correccin

Hace que se incluya la correccin tan aguas arriba como sea posible. Hacindolo puede garantizar que todo el mundo obtiene el cdigo aguas arriba tal cual es y que no necesita realizar modicaciones locales para arreglarlo. En nuestro caso establecimos que tenemos un problema con el empaquetado, tanto en Ubuntu como en Debian. Como Ubuntu se basa en Debian, enviaremos la correccin a Debian. Una vez que se incluya ah, ser recogida por Ubuntu en algn momento. La incidencia en nuestro tutorial claramente es no crtica, as que este enfoque tiene sentido. Si fuera importante corregir la incidencia cuanto antes, necesitar enviar la correccin a varios registros de errores, suponiendo que la incidencia afecte a todas las partes en cuestin. Para enviar el parche a Debian, simplemente ejecute:
submittodebian
Esto le llevar por una serie de pasos para asegurarse de que el error termina en el lugar adecuado. Asegrese de revisar de nuevo el archivo de differencias (diff) para tener certeza de que no incluye cambios aleatorios que haya realizado anteriormente. La comunicacin es importante, as que cuando aada algo ms de descripcin a la peticin de inclusin, sea amigable y explquelo bien. Si todo ha ido bien debera recibir un correo desde el sistema de registro de errores de Debian con ms informacin. Esto podra llevar unos minutos. Nota: Si el problema est solo en Ubuntu, debera considerar pedir que lo revisen y lo patrocinen (Seeking Review and Sponsorship) para que se incluya la correccin.
1.5.8 Consideraciones adicionales:

Si encuentra un paquete y existen un par de cosas triviales que puede corregir al mismo tiempo, hgalo. Esto acelerar su revisin e inclusin. Si hay varias cosas importantes que quiera arreglar, sera recomendable enviar parches individuales o peticiones de integracin. Si se han rellenado errores independientes para las incidencias, lo hace incluso ms fcil.
1.6 Empaquetando nuevo software

A pesar de que hay miles de paquetes en el repositorio de Ubuntu, todava hay muchos que nadie ha conseguido. Si hay una nueva y excitante porcin de software que siente que necesita una exposicin ms amplia, quiz quiera intentar crear un paquete para Ubuntu o un PPA. Esta gua le acompaar a travs de los pasos del empaquetado de nuevo software. Probablemente quiera leer el artculo Getting Set Up antes para preparar su entorno de desarrollo.
1.6.1 Comprobar el programa

La primera fase del empaquetado es obtener el archivo tar liberado aguas arriba (llamamos a los autores de las aplicacin aguas arriba, upstream) y comprobar que compila y se ejecuta. Esta gua le llevar a travs del empaquetado de una aplicacin sencilla llamada GNU Hello, la cual ha sido publicada en GNU.org.
1.6. Empaquetando nuevo software
19
Si no tiene las herramientas de compilacin asegrese de obtenerlas antes. Si tampoco tiene instaladas todas las dependencias necesarias, instlelas igualmente. Instalar herramientas de compilacin:
$ sudo apt-get install build-essential
Descargar el paquete main:

$ wget -O hello-2.7.tar.gz "http://ftp.gnu.org/gnu/hello/hello-2.7.tar.gz"
Descomprimir el paquete main:

$ tar xf hello-2.7.tar.gz $ cd hello-2.7
Esta aplicacin usa el sistema de compilacin autoconf, as que debemos ejecutar ./congure para preparar la compilacin. Esto comprobar las dependencias de compilacin necesarias. Como hello es un ejemplo sencillo, build-essential debera proporcionar todo lo que necesitamos. Para programas ms complejos, la orden fallar si no tiene las bibliotecas y archivos de desarrollo necesarios. Instale los paquetes necesarios y repita hasta que la orden se ejecute correctamente.:
$ ./configure
Ahora puede compilar el fuente:

$ make
Si la compilacin naliza con xito puede instalar y ejecutar el programa:

$ sudo make install $ hello
1.6.2 Iniciar un paquete

bzr-builddeb incluye un complemento para crear nuevos paquetes a partir de una plantilla. El complemento es un envoltorio alrededor de la orden dh_make. Ya debera tenerlos instalados si instal packaging-dev. Ejecute la orden indicando el nombre del paquete, nmero de versin y la ruta al archivo tar de aguas arriba:
$ sudo apt-get install dh-make $ cd .. $ bzr dh-make hello 2.7 hello-2.7.tar.gz
Cuando pregunte por el tipo de paquete escriba s para binario simple. Esto importar el cdigo en u n rama y aadir el directorio de empaquetado debian/. Eche un vistazo al contenido. La mayora de los archivos que aade son slo necesarios para paquetes especialistas (como los mdulos de Emacs) as que puede comenzar por eliminar los archivos de ejemplo opcionales:
$ cd hello/debian $ rm *ex *EX
Ahora debera personalizar cada uno de los archivos. En debian/changelog cambie el nmero de versin a una versin de Ubuntu: 2.7-0ubuntu1 (versin aguas arriba 2.7, versin Debian 0, versin Ubuntu 1). Cambie tambin unstable a la versin de desarrollo de Ubuntu actual, como precise
20
Mucho del trabajo de construccin de paquetes se realiza por una serie de scripts llamados debhelper. El comportamiento exacto de debhelper cambia con cada nueva versin mayor, el archivo compat indica a debhelper como qu versin actuar. Generalmente querr establecerlo a la versin ms reciente que es la 8. control contiene todos los metadatos del paquete. El primer prrafo describe el paquete fuente. El segundo y siguientes describen los paquetes binarios a construir. Necesitaremos aadir los paquetes necesarios para compilar la aplicacin a Build-Depends:. Para hello, asegrese de que incluye al menos:
Build-Depends: debhelper (>= 8.0.0)
Tambin necesitar rellenar la descripcin del programa en el campo Description:. Debe rellenar copyright para que siga la licencia de los fuentes aguas arriba. Segn el archivo hello/COPYING es GNU GPL 3 o superior. docs contiene cualquier archivo de documentacin de aguas arriba que piense que debera ser incluido en el paquete nal. README.source y README.Debian solo son necesarios si su paquete tiene caractersticas no estndar. No las tiene, as que se pueden borrar. source/format se puede dejar como est. Describe el formato de la versin del paquete fuente y debera ser 3.0 (quilt). rules es el archivo ms complejo. Es un Makele que compila el cdigo y lo convierte en un paquete binario. Afortunadamente la mayor parte del trabajo hoy en da se realiza automticamente por debhelper 7 as que el objetivo Makele % universal simplemente ejecuta el script dh que a su vez ejecutar todo lo que haga falta. Todos estos archivos se explican con ms detalle en el artculo resumen del directorio debian. Finalmente conrme el cdigo en su rama de empaquetado:
$ bzr commit -m "Initial commit of Debian packaging."
1.6.3 Construir el paquete

Ahora necesitamos comprobar que el empaquetado compila con xito el paquete y genera el paquete binario .deb:
$ bzr builddeb -- -us -uc $ cd ../../
bzr builddeb es una orden para compilar el paquete en su ubicacin actual. Los parmetros -us -uc le indicarn que no es necesario rmar con GPG el paquete. El resultado se dejar en ... Puede ver el contenido del paquete con:
$ lesspipe hello_2.7-0ubuntu1_amd64.deb
Instale el paquete y compruebe que funcione:

$ sudo dpkg --install hello_2.7-0ubuntu1_amd64.deb
1.6.4 Siguientes pasos

Incluso si genera el paquete binario .deb, el empaquetado puede contener errores. Muchos errores se pueden detectar automticamente mediante la herramienta lintian que se puede ejecutar tanto sobre el archivo fuente .dsc de metadatos como sobre el paquete binario .deb:
21
$ lintian hello_2.7-0ubuntu1.dsc $ lintian hello_2.7-0ubuntu1_amd64.deb
Se puede encontrar una descripcin de los problemas que reporta en el sitio web de lintian lintian website. Despus de realizar una correccin al empaquetado puede reconstruirlo usando la opcin -nc (no clean, sin limpiar) para no tener que compilarlo desde el principio:
$ bzr builddeb -- -nc -us -uc
Despus de comprobar que el paquete se compila en local debera asegurarse de que lo hace tambin en un sistema limpio usando pbuilder. Puesto que se va a subir en breve a un PPA (archivo de paquetes personal), esta proceso de subida deber ser rmado para permitir a Launchpad que verique que la carga proviene de usted (puede saber que la carga se rmar porque no se pasan los marcadores -us y -uc a bzr builddeb como se hizo antes). Para rmar su trabajo necesita haber congurado GPG. Si no ha congurado todava pbuilder-dist o GPG todava, do so now:
$ bzr builddeb -S $ cd ../build-area $ pbuilder-dist precise build hello_2.7-0ubuntu1.dsc
Cuando est satisfecho con su paquete desear que otros lo revisen. Puede subirlo la rama a Launchpad para su revisin:
$ bzr push lp:~<lp-username>/+junk/hello-package
Al subirlo a un PPA se asegurar de que compila y le proporcionar una manera fcil de probar los paquetes binarios para usted y para otros. Necesitar congurar un PPA en Launchpad y luego cargarlo con dput:
$ dput ppa:<lp-username> hello_2.7-0ubuntu1.changes
Vase subir para ms informacin. Puede pedir que se revise en el canal de IRC #ubuntu-motu, o en la lista de correo de MOTU mailing list. Tambin podra existir un equipo ms especco al que se lo podra solicitar como el equipo GNU para temas ms concretos.
1.6.5 Enviar para su inclusin

Existe varios caminos por los que un paquete puede entrar en Ubuntu. En la mayora de los casos, ir antes por Debian puede ser la mejor alternativa. De esta forma se asegura de que su paquete llegar al mayor nmero de usuarios, ya que tambin estar disponible no solo para Debian y Ubuntu, sino para todos sus derivados tambin. Estos son algunos enlaces tiles para enviar nuevos paquetes a Debian: Debian Mentors FAQ - debian-mentors est para la tutora de nuevos y futuros desarrolladores de Debian. Es el lugar en el que puede encontrar un patrocinador que suba su paquete al repositorio. Work-Needing and Prospective Packages - Informacin sobre cmo presentar errores Intencin de empaquetar y Peticin para empaquetar as como una lista de ITPs y RFPs abiertos. Debian Developers Reference, 5.1. New packages- El documento completo es una fuente inestimable para empaquetadores tanto de Ubuntu como de Debian. Esta seccin documenta el proceso de envo de nuevos paquetes. En algunos casos, podra tener sentido ir directamente a Ubuntu antes. Por ejemplo, Deban podra encontrarse en congelacin haciendo que sea improbable que su paquete llegue a Ubuntu a tiempo para la prxima emisin. Este proceso est documentado en la seccin New Packages de la wiki de Ubuntu.
22
1.7 Actualizaciones de seguridad y de versiones estables

1.7.1 Corregir un error de seguridad en Ubuntu
Introduccin Corregir errores de seguridad no es en tan distinto de corregir un error normal en Ubuntu, y se asume que est familiarizado con el parcheo de errores normales. Para mostrar dnde se hacen las cosas de forma diferente, actualizaremos el paquete dbus en Ubuntu 10.04 LTS (Lucid Lynx) para incluir una actualizacin de seguridad. Obtener el cdigo fuente En este ejemplo, ya sabemos que deseamos corregir el paquete dbus en Ubuntu10.04 LTS (Lucid Lynx). As que lo primero es determinar la versin del paquete que quiere descargar. Puede usar rmadison para que le ayude:
$ rmadison dbus | grep lucid dbus | 1.2.16-2ubuntu4 | lucid | source, amd64, i386 dbus | 1.2.16-2ubuntu4.1 | lucid-security | source, amd64, i386 dbus | 1.2.16-2ubuntu4.2 | lucid-updates | source, amd64, i386
Habitualmente desear seleccionar la versin ms alta para la emisin que pretende parchear que no est en -proposed o -backports. Ya que estamos actualizando el dbus de Lucid, descargar 1.2.16-2ubuntu4.2 from lucid-updates:
$ bzr branch ubuntu:lucid-updates/dbus
Parchear el cdigo fuente Ahora que ya tenemos el paquete fuente, necesitamos parchearlo para corregir la vulnerabilidad. Puede usar cualquier mtodo que sea adecuado para el paquete, incluyendo tcnicas UDD, pero para este ejemplo se usar edit-patch (del paquete ubuntu-dev-tools). edit-patch es la forma ms sencilla de parchear paquetes y bsicamente se trata de un envoltorio alrededor de todos los dems sistemas de parches que pueda imaginar. Para crear un parche usando edit-patch:
$ cd dbus $ edit-patch 99-fix-a-vulnerability
Esto aplicar los parches existentes y dejar el empaquetado en un directorio temporal. Ahora edite los archivos necesarios para solucionar la vulnerabilidad. Frecuentemente se habr proporcionado un parche desde aguas arriba de forma que pueda aplicarlo:
$ patch -p1 < /home/user/dbus-vulnerability.diff
Despus de hacer los cambios necesarios, simplemente pulse Ctrl+D o escriba exit para dejar el intrprete de rdenes temporal. Formatear el registro de cambios (changelog) y los parches Despus de aplicar los parches desear actualizar el registro de cambios (changelog). La orden dch se usa para editar el archivo debian/changelog y edit-patch lanzar dch automticamente despus de des-aplicar todos los parches. Si no est usando edit-patch, puede lanzar dch -i manualmente. A diferencia de los parches normales, debera usar el siguiente formato (note que el nombre de la distribucin usa lucid-security, ya que se trata de una actualizacin de seguridad para Lucid) para actualizaciones de seguridad:
1.7. Actualizaciones de seguridad y de versiones estables
23
dbus (1.2.16-2ubuntu4.3) lucid-security; urgency=low * SECURITY UPDATE: [DESCRIBE VULNERABILITY HERE] - debian/patches/99-fix-a-vulnerability.patch: [DESCRIBE CHANGES HERE] - [CVE IDENTIFIER] - [LINK TO UPSTREAM BUG OR SECURITY NOTICE] - LP: #[BUG NUMBER] ...
Actualice su parche para usar las etiquetas de parche adecuadas. Su parche debera tener por lo menos las etiquetas Origin, Description y Bug-Ubuntu. Por ejemplo, edite debian/patches/99-x-a-vulnerability.patch para que tenga es siguiente aspecto:
## Description: [DESCRIBE VULNERABILITY HERE] ## Origin/Author: [COMMIT ID, URL OR EMAIL ADDRESS OF AUTHOR] ## Bug: [UPSTREAM BUG URL] ## Bug-Ubuntu: https://launchpad.net/bugs/[BUG NUMBER] Index: dbus-1.2.16/dbus/dbus-marshal-validate.c ...
Muchas vulnerabilidades se puede solucionar en la misma carga de seguridad, pero asegrese de usar parches distintos para las diferentes vulnerabilidades. Probar y enviar el trabajo En este punto el proceso es el mismo que para arreglar un bug normal de Ubuntu. Ms concretamente, desear: 1. Construir el paquete y comprobar que compila sin errores y sin ningn aviso del compilador aadido. 2. Actualizar a la nueva versin del paquete desde la versin anterior 3. Probar que el nuevo paquete corrige la vulnerabilidad y no introduce ninguna regresin 4. Enviar el trabajo mediante una propuesta de integracin de Launchpad y rellenar un error en Launchpad asegurndose de marcar el error como un fallo de seguridad y de suscribirse a ubuntu-security-sponsors. Si la vulnerabilidad de seguridad no es pblica todava no presente una propuesta de integracin y asegrese de marcar el error como privado. El presentado debe incluir un caso de prueba, es decir, un comentario que indique claramente cmo recrear el error ejecutando la versin antigua y luego cmo asegurarse de que el error no existe en la nueva versin. El informe de error debera tambin conrmar que la incidencia est solucionada en versiones ms recientes de Ubuntu que la que incluye la correccin propuesta (en el ejemplo anterior, ms modernas que Lucid). Si la incidencia no est solucionada en versiones ms modernas de Ubuntu debera preparar las actualizaciones tambin para esas versiones.
1.7.2 Actualizaciones de versiones estables

Tambin se permite actualizaciones de emisiones en las que un paquete tiene un error de gran impacto, como por ejemplo una regresin severa de una emisin anterior o un error que podra causar prdida de datos. Debido al potencia de que esas actualizaciones a su vez introduzcan errores solo se permiten cuando los cambios pueden ser fcilmente comprendidos y vericados. El proceso de actualizaciones de versiones estables es el mismo que el proceso para errores de seguridad excepto que debera suscribir ubuntu-sru al error. La actualizacin ir al repositorio proposed (por ejemplo, lucid-proposed) donde se deber comprobar que soluciona el problema y no introduce nuevos errores. Despus de una semana sin problemas reportados se puede mover a updates. 1.7. Actualizaciones de seguridad y de versiones estables 24
Vase la Stable Release Updates wiki page_ para ms informacin.
1.8 Parches a los paquetes

A veces, los mantenedores de paquetes de Ubuntu tienen que cambiar el cdigo fuente recibido desde aguas arriba para que funcione correctamente en Ubuntu. Ejemplos de esto incluyen parches aguas arriba que no han llegado todava a la versin emitida, o cambios al sistema de compilacin aguas arribas que son necesarios nicamente para compilarlos en Ubuntu. Se podra cambiar el cdigo recibido de aguas arriba directamente, pero al hacerlo que diculta la eliminacin de los parches posteriormente cuando se hayan incorporado los cambios aguas arriba, o extraer el cambio para enviarlo al proyecto aguas arriba. En su lugar, se mantienen los cambios como parches independientes, en forma de archivos de diferencias (diff). Hay varias formas diferentes de gestionar los parches de paquetes de Debian, aunque afortunadamente se est estandarizando en un nico sistema, Quilt, que se usa ya para la mayora de los paquetes. Vemoslo con un paquete de ejemplo, kamoso en Natty:
$ bzr branch ubuntu:natty/kamoso
Los parches se mantienen en debian/patches. Este paquete tiene un parche kubuntu_01_fix_qmax_on_armel.diff para arreglar un fallo de compilacin en ARM. Al parche se le ha dado un nombre descriptivo de lo que hace, un nmero para mantener los parches ordenados (dos parches se puede solapar si cambian el mismo archivo) y en este caso el equipo de Kubuntu aade su propio prejo para mostrar que el parche proviene de ellos en lugar de venir de Debian. El orden de los parches a aplicar se mantiene en debian/patches/series.
1.8.1 Parches con Quilt

Antes de comenzar a trabajar con Quilt necesita indicarle dnde encontrar los parches. Adalo a su archivo ~/.bashrc:
export QUILT_PATCHES=debian/patches
Y como fuente el archivo para aplicar la nueva exportacin:

$ . ~/.bashrc
Por defecto todos los parches ya estn aplicados a las extraccin UDD o a los paquetes descargados. Puede comprobarlo con:
$ quilt applied kubuntu_01_fix_qmax_on_armel.diff
Si quera eliminar el parche debera ejecutar pop:

$ quilt pop Removing patch kubuntu_01_fix_qmax_on_armel.diff Restoring src/kamoso.cpp No patches applied
Y para aplicar un parche use push:

$ quilt push Applying patch kubuntu_01_fix_qmax_on_armel.diff patching file src/kamoso.cpp
1.8. Parches a los paquetes
25
Now at patch kubuntu_01_fix_qmax_on_armel.diff
1.8.2 Aadir un nuevo parche

Para aadir un nuevo parche necesita indicarle a Quilt que cree un nuevo parche, qu archivos debera cambiar ese parche, editar los archivos y refrescar el parche:
$ quilt new kubuntu_02_program_description.diff Patch kubuntu_02_program_description.diff is now on top $ quilt add src/main.cpp File src/main.cpp added to patch kubuntu_02_program_description.diff $ sed -i "s,Webcam picture retriever,Webcam snapshot program," src/main.cpp $ quilt refresh Refreshed patch kubuntu_02_program_description.diff
El paso quilt add es importante, si lo olvida los archivos no terminarn en el parche. El cambio estar ahora en debian/patches/kubuntu_02_program_description.diff y en el archivo series se habr aadido el parche. Ahora debera aadir el archivo al empaquetado:
$ $ $ $ bzr bzr dch bzr add debian/patches/kubuntu_02_program_description.diff add .pc/* -i "Add patch kubuntu_02_program_description.diff to improve the program description" commit
Quilt mantiene sus metadatos en el directorio .pc/, as que actualmente necesita aadirlo tambin al empaquetado. Esto debera mejorarse en el futuro. Como regla general debera tener cuidado al aadir parches a programas a menos que lleguen desde aguas arriba, frecuentemente hay una buena razn para que el cambio no se haya hecho todava. El ejemplo anterior cambia una cadena de la interfaz de usuario por ejemplo, as que invalidara todas las traducciones. Si duda, pregunte al autor aguas arriba antes de aadir el parche.
1.8.3 Cabeceras de parche

Le recomendamos que etiquete cada parche con cabeceras DEP-3 aadindolas al comienzo de cada archivo de parche. Estas son algunas de las cabeceras que puede usar: Description Descripcin de lo que hace el parche. Author Quin escribi el parque (por ejemplo, Juana Nadie <empaquetador@ejemplo.com>). Origin De dnde proviene el parche (por ejemplo, upstream, aguas arriba), cuando no se indica el autor (Author). Bug-Ubuntu Un enlace al error en Launchpad, prerindose una forma corta (como https://bugs.launchpad.net/bugs/XXXXXXX ). Si existen tambien errores aguas arriba o , aadir cabeceras Bug o Bug-Debian. Forwarded Si el parche se reenvi aguas arriba. Uno de yes (s), no (no) o not-needed (no necedsario). Last-Update Fecha de la ltima revisin (en formato YYYY-MM-DD).
26
1.8.4 Actualizar a nuevas versiones de aguas arriba

Para actualizar a la nueva versin, puede usar la orden bzr merge-upstream:
$ bzr merge-upstream --version 2.0.2 https://launchpad.net/ubuntu/+archive/primary/+files/kamoso_2.0.
Cuando ejecute esa orden, se des-aplicarn todos los parches, porque pueden quedarse obsoletos. Podra ser necesario refrescarlos para que se adapten al nuevo cdigo fuentes aguas arriba o deban ser eliminados completamente. Para comprobar posibles problemas, aplique los parches uno a uno:
$ quilt push Applying patch kubuntu_01_fix_qmax_on_armel.diff patching file src/kamoso.cpp Hunk #1 FAILED at 398. 1 out of 1 hunk FAILED -- rejects in file src/kamoso.cpp Patch kubuntu_01_fix_qmax_on_armel.diff can be reverse-applied
Si puede ser aplicado a la inversa signica que el parche ya ha sido aplicado aguas arriba, de forma que ya se puede borrar:
$ quilt delete kubuntu_01_fix_qmax_on_armel Removed patch kubuntu_01_fix_qmax_on_armel.diff
Luego contine:
$ quilt push Applied kubuntu_02_program_description.diff
Es una buena idea hacer un refresco, lo que actualizar el parche relativo a los fuentes cambiados aguas arriba:
$ quilt refresh Refreshed patch kubuntu_02_program_description.diff
Luego conrme como siempre:

$ bzr commit -m "new upstream version"
1.8.5 Hacer que un paquete use Quilt

Los paquetes modernos usan Quilt de forma predeterminada, estn incluido en el formato de empaquetado. Compruebe debian/source/format para asegurarse que pone 3.0 (quilt). Los paquetes ms antiguos que usen el formato fuente 1.0 necesitarn usar Quilt explcitamente, normalmente incluyendo un archivo makele en debian/rules.
1.8.6 Congurando Quilt

Puede usar el archivo ~/.quiltrc para congurar quilt. Estas son algunas opciones que pueden resultar tiles para usar quilt con paquetes debian:
# Set the patches directory QUILT_PATCHES="debian/patches" # Remove all useless formatting from the patches QUILT_REFRESH_ARGS="-p ab --no-timestamps --no-index" # The same for quilt diff command, and use colored output QUILT_DIFF_ARGS="-p ab --no-timestamps --no-index --color=auto"
27
1.8.7 Otros sistemas de parches

Otros sistemas de parches que se usan por los paquetes incluyen dpatch y cdbs simple-patchsys, los cuales funcionan de forma similar a Quilt, manteniendo los parches en debian/patches, pero emplean rdenes distintas para aplicar, des-aplicar o crear parches. Puede averiguar qu sistema de parches se usa por un paquete mediante la orden what-patch (del paquete ubuntu-dev-tools). Puede usar edit-patch, como se ha mostrado en captulos previos, como una manera able de trabajar con todos los sistemas. En paquetes todava ms antiguos los cambios se incluirn directamente en los fuentes y los mantendrn el archivo fuente diff.gz. Esto complica la actualizacin a nuevas versiones de aguas arribas o distinguir entre parches por lo que lo mejor es evitarlo. No cambie el sistema de parches de un paquete sin haberlo discutido con el mantenedor de Debian o el equipo pertinente de Ubuntu. Si no existe un sistema parches no tenga problemas en aadir Quilt.
1.9 Bibliotecas compartidas

Las bibliotecas compartidas es cdigo compilado que se supone que ser compartido por diferentes programas. Se distribuyen como archivos .so en /usr/lib/. Una biblioteca exporta smbolos que son versiones compiladas de funciones, clases y variables. Una biblioteca tiene un nombre denominado SONAME que incluye un nmero de versin. Esta versin de SONAME no tiene por qu coincidir con el nmero de versin de emisin pblica. Un programa se compila contra una versin determinada de SONAME de la biblioteca. Si cualquiera de los smbolos es eliminado o modicado, entonces el nmero de versin debe ser cambiado lo que fuerza que que cualquier paquete que use la biblioteca sea recompilado contra la nueva versin. Los nmeros de versiones normalmente son establecidos aguas arriba y los mantenemos en los nombres de los paquetes binarios, llamado nmero ABI, pero en ocasiones aguas arriba no usan nmeros de versiones razonables y los empaquetadores tienen que mantener nmeros de versiones separados. Las bibliotecas se distribuyen normalmente aguas arriba como emisiones independientes. Algunas veces se distribuyen como partes de un programa. En este caso se pueden incluir en el paquete binario junto con el programa (esto se denomina bundling, atado) si no espera que ningn otro programa use la biblioteca, pero lo ms frecuente es que sean separadas en paquetes binarios independientes. Las propias bibliotecas se meten en un paquete binario llamado libfoo1 donde foo es el nombre de la biblioteca y 1 es la versin del SONAME. Los archivos de desarrollo del paquete, como los archivos de cabecera, necesitan compilar programas contra la biblioteca que se ha metido en el paquete llamado libfoo-dev.
1.9.1 Un ejemplo
Usaremos libnova como un ejemplo:
$ bzr branch ubuntu:natty/libnova $ sudo apt-get install libnova-dev
Para encontrar el SONAME de una biblioteca ejecute:

$ readelf -a /usr/lib/libnova-0.12.so.2 | grep SONAME
El SONAME es libnova-0.12.so.2, lo que coincide con el nombre del archivo (es lo normal, pero no siempre ocurre). En este caso aguas arriba han puesto el nmero de versin como parte del SONAME y le han dado una versin ABI de 2. Los nombres de paquetes de bibliotecas deberan seguir el SONAME de la biblioteca que contienen. El paquete binario de la biblioteca se llama libnova--0.12-2, donde libnova-0.12 es el nombre de la biblioteca y 2 es nuestro nmero ABI.
1.9. Bibliotecas compartidas
28
SI aguas arriban hacen cambios incompatible a su biblioteca tendr que revisionar su SONAME y nosotros tendremos que cambiar de nombre a nuestra biblioteca. Cualquier otro paquete que use nuestra biblioteca deber ser recompilado contra la nueva versin, esto es lo que se llama una transicin y puede suponer cierto esfuerzo. Afortunadamente nuestro nmero ABI seguir coincidiendo con el SONAME de aguas arriba, pero en ocasiones se introducen incompatibilidades sin cambiar el nmero de versin lo que nos fuerza a hacer cambios en el nuestro. Si miramos en debian/libnova-0.12-2.install vemos que incluye estos dos archivos:
usr/lib/libnova-0.12.so.2 usr/lib/libnova-0.12.so.2.0.0
El ltimo es la biblioteca en s, completada con el nmero de menor de la versin y punto. El primero es un enlace simblico que apunta a la biblioteca real. El enlace simblico es lo que buscarn los programas que empleen la biblioteca, ya que los programas que se ejecutan no se preocupan por el nmero de menor de la versin. libnova-dev.install incluye todo los archivos necesarios para compilar un programa con esta biblioteca. Los archivo de cabeceras, una conguracin binaria, el archivo .la de libtool y libnova.so que es otro enlace simblico apuntando a la misma biblioteca, programas compilados contra la biblioteca no se preocupan del nmero mayor de la versin (aunque el binario en el que se compilarn s lo har). Los archivos .la de libtool son necesarios en algunos sistemas no-Linux con soporte de bibliotecas pobre, pero en sistemas Debian normalmente causan ms problemas que los que resuelven. Actualmente es un objetivo de Debian eliminar los archivos .la (Debian goal to remove .la les) y deberamos ayudar a hacerlo.
1.9.2 Bibliotecas estticas

El paquete -dev tambin incluye usr/lib/libnova.a. Es una biblioteca esttica, una alternativa a las libreras compartidas. Cualquier programa compilado contra una biblioteca esttica incluya el directorio de cdigo dentro de s mismo. Esto evita tener que preocuparse sobre la compatibilidad binaria de la biblioteca. Sin embargo, tambin signica que cualquier error, incluyendo las incidencias de seguridad, no sern actualizados junto con la biblioteca hasta que se recompile el programa. Por esta razn se desaconseja el uso de programas que usen libreras estticas.
1.9.3 Archivos de smbolos

Cuando un paquete se compila contra una biblioteca el mecanismo de shlibs aadir una dependencia del paquete a esa biblioteca. Este es el motivo de que la mayora de los programas tengan Depends: ${shlibs:Depends} en el archivo debian/control. Eso se sustituye por las dependencias de la biblioteca en tiempo de compilacin. Sin embargo, shlibs solo puede hacerla depender del nmero mayor de versin ABI, 2 en el ejemplo, as que si se aaden nuevos smbolos a libnova 2.1 un programa que use estos smbolos podra todava seguir instalado contra libnova ABI 2.0, lo que podra producir un fallo. Para hacer ms precisas las dependencias de las bibliotecas matenemos archivos .symbols que listan todos los smbolos de una librera y la versin en la que aparecen. libnova no tiene archivo de smbolos as que podemos crear uno. Comience por compilar el paquete:
$ bzr builddeb -- -nc
La opcin -nc har que se nalice al completar la compilacin sin que se eliminen los archivos compilados. Cmbiese al directorio compilado y ejecute dpkg-gensymbols para el paquete de la biblioteca:
$ cd ../build-area/libnova-0.12.2/ $ dpkg-gensymbols -plibnova-0.12-2 > symbols.diff
Esto genera un archivo de diferencias (diff) que puede aplicar:
1.9. Bibliotecas compartidas
29
$ patch -p0 < symbols.diff
Lo que crear un archivo con un nombre similar a dpkg-gensymbolsnY_WWI que lista todos los smbolos. Tambin lista la versin de paquete actual. Podemos eliminar la versin de empaquetado que se lista en el archivo de smbolos porque generalmente no se aaden nuevos smbolos por versiones ms modernas de empaquetado, sino por los desarrolladores aguas arriba:
$ sed -i s,-0ubuntu2,, dpkg-gensymbolsnY_WWI
Ahora mueva el archivo a su ubicacin, conrme y haga una prueba de compilacin:

$ $ $ $ $ mv dpkg-gensymbolsnY_WWI ../../libnova/debian/libnova-0.12-2.symbols cd ../../libnova bzr add debian/libnova-0.12-2.symbols bzr commit -m "add symbols file" bzr builddeb
Si compila con xito es que el archivo de smbolos es correcto. Con la siguiente versin aguas arriba de libnova podra ejecutar de nuevo dpkg-gensymbols y obtendr un archivo de diferencias para actualizar el archivo de smbolos.
1.9.4 Archivos de smbolos de bibliotecas de C++

C++ tiene estndares de compatibilidad binaria incluso ms exigentes que C. El equipo Qt/KDE de Debian mantiene algunos scripts para gestionarlo. Vase su pgina Working with symbols les para saber cmo usarlos.
1.9.5 Lecturas adicionales

Debian Library Packaging Guide (gua de empaquetado de bibliotecas Debian) de Junichi Uekawa profundiza en estos temas con ms detalle.
1.10 Adaptar actualizaciones de software a versiones anteriores

En ocasiones podra desear hacer disponible una nueva funcionalidad de una emisin estable que no est relacionada con la correccin de un error crtico. Para estos escenarios existen dos opciones: o bien upload to a PPA o bien prepara una adaptacin a la versin antigua.
1.10.1 Archivo de paquetes personal (Personal Package Archive, PPA)

Usar un PPA tiene una serie de ventajas. Es bastante directo, no necesita la aprobacin de nadie, pero la desventaja es que sus usuarios tendrn que activarlo manualmente. Es un origen de software no estndar. PPA documentation on Launchpad es bastante completo y debera tenerlo funcionando en poco tiempo.
1.10.2 Adaptaciones ociales a versiones anteriores de Ubuntu

El proyecto Backports (adaptaciones a versiones antiguas) es un medio de proporcionar nuevas funcionalidades a los usuarios. Debido al riesgo inherente de afectar a la estabilidad al adaptar los paquetes a versiones antiguas, los usuarios no obtienen estos paquetes sin algn tipo de accin explcita por su parte. Esto generalmente convierte a las adaptaciones en camino poco adecuado para corregir errores. Si un paquete en una emisin de Ubuntu tiene un error, debera ser corregido mediante los procesos descritos en Security Update or the Stable Release Update process, segn sea corresponda. 1.10. Adaptar actualizaciones de software a versiones anteriores 30
Una vez haya determinado que quiere adaptar un paquete a una versin estable, necesitar hacer una compilacin de prueba y probarla sobre dicha versin estable. pbuilder-dist (del paquete ubuntu-dev-tools) es una herramienta muy prctica para hacerlo fcilmente. Para reportar una peticin de adaptacin y hacer que el equipo de Backporters la procese, puede usar la herramienta requestbackport (tambin del paquete ubuntu-dev-tools). Esta herramienta determinar las emisiones intermedias a las que el paquete necesita ser adaptado, listar todas las dependencias inversas y rellenar la peticin de adaptacin. Tambin incluir una lista de comprobacin en el error.
1.10. Adaptar actualizaciones de software a versiones anteriores
31
CAPTULO 2
Base de conocimiento
2.1 Comunicacin en el desarrollo de Ubuntu

En un proyecto donde se modican miles de lneas de cdigo, se toman muchas decisiones y miles de personas interactan a diario, es importante comunicarse ecazmente.
2.1.1 Listas de correo

Las listas de correo son una herramienta importante si quiere comunicar ideas a un equipo ms grande y asegurarse de llegar a todos, incluso en distintas zonas horarias. En trminos de desarrollo, estos son los ms importantes: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce (Solo anuncios, los anuncios ms importantes sobre desarrollo van aqu) https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel (discusin general de desarrollo de Ubuntu) https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu (Discusin del equipo MOTU, para obtener ayuda con el empaquetado)
2.1.2 Canales IRC

Para discusiones en tiempo real, conctese a irc.freenode.net y nase a alguno de estos canales: #ubuntu-devel (para discusiones generales sobre desarrollo) #ubuntu-motu (para discusiones del equipo MOTU y solicitar ayuda generalmente)
2.2 Descripcin general bsica del Directorio debian/

En este artculo explicaremos brevemente los diferentes archivos que son importantes para el empaquetado de paquetes Ubuntu los cuales estn en el directorio debian/. Los ms importantes son changelog, control, copyright y rules. Estos son requeridos por todos los paquetes. Un conjunto de archivos adicionales en debian/ puede que sean usados para personalizar y congurar el comportamiento del paquete. Sobre algunos de ello se habla en este articulo, pero esto no pretende ser una lista completa.
32
2.2.1 El registro de cambios

Este archivo es, como su nombre indica, un listado de los cambios realizados en cada versin. Tiene un formato especico que da el nombre del paquete, versin, distribucin, cambios, y quin realiz estos cambios en un determinado momento. Si tiene una clave GPG (vea: Getting set up), asegrese de usar el mismo nombre y direccin de correo electrnico en changelog. tal y cmo lo tiene en la clave. Lo siguiente es una plantilla de changelog:
package (version) distribution; urgency=urgency * change details - more change details * even more change details -- maintainer name <email address>[two spaces] date
El formato (especialmente el de la fecha) es importante. La fecha debe estar en formato RFC 5322, que puede obtenerse mediante la orden date -R. Por conveniencia, la orden dchx se puede usar para editar el archivo changelog. Se actualizar la fecha de forma automtica. Los puntos de segundo nivel se indican con un guin -, los de primer nivel usan un asterisco *. Si est empaquetando desde cero, dch --create (dch se encuentra en el paquete devscripts) crear un archivo debian\changelog estndar. Este es un ejemplo del archivo changelog para hello:
hello (2.6-0ubuntu1) natty; urgency=low * New upstream release with lots of bug fixes and feature improvements. -- Jane Doe <packager@example.com> Thu, 21 Apr 2011 11:12:00 -0400
Observe que el paquete tiene un -0ubuntu1 anexado a el, este representa la versin en la distribucin y se usa para que el paquete pueda ser actualizado (para solucionar errores por ejemplo) con nuevas subidas usando la misma versin principal con la que se liber. Ubuntu y Debian tienen esquemas de versin de paquetes ligeramente diferentes para evitar conictos en los programas con la misma versin principal. Si una paquete de Debian sufre un cambio en Ubuntu, se le agrega el ubuntuX (donde X es el nmero de revisin en Ubuntu) al nal de la versin de Debian. Si el paquete hello 2.6-1 de Debian es modicado en Ubuntu, la versin quedara 2.6-1ubuntu1. Si el paquete no existiera en Debian, entonces la revisin ah sera 0 (y quedara 2.6-0ubuntu1). Para obtener ms informacin, consulte la seccin de cambios (Section 4.4) <http://www.debian.org/doc/debianpolicy/ch-source.html#s-dpkgchangelog>_ del Manual de normas de Debian.
2.2.2 El archivo de control

El archivo control contiene la informacin que usan administradores de paquetes (como apt-get, synaptic y adept), dependencias de compilacin, informacin del mantenedor y mucho ms. Para el paquete hello de Ubuntu, el archivo control tiene el siguiente aspecto:
Source: hello Section: devel Priority: optional Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com> XSBC-Original-Maintainer: Jane Doe <packager@example.com> Standards-Version: 3.9.1 Build-Depends: debhelper (>= 7)
2.2. Descripcin general bsica del Directorio debian/
33
Bzr-Vcs: lp:ubuntu/hello Homepage: http://www.gnu.org/software/hello/ Package: hello Architecture: any Depends: ${shlibs:Depends} Description: The classic greeting, and a good example The GNU hello program produces a familiar, friendly greeting. It allows non-programmers to use a classic computer science tool which would otherwise be unavailable to them. Seriously, though: this is an example of how to do a Debian package. It is the Debian version of the GNU Projects hello world program (which is itself an example for the GNU Project).
El primer prrafo describe el paquete fuente incluyendo la lista de paquetes requeridos para construirlo desde sus fuentes en el campo Build-Depends. Tambin contiene alguna meta-informacin como el nombre del mantenedor, la versin de la poltica de Debian que cumple el paquete, la ubicacin del repositorio de control de versiones del paquete y la pgina principal para enviar el parche. Tenga en cuenta que en Ubuntu, se congura el campo Maintainer a una direccin general porque cualquiera puede cambiar cualquier paquete (esto se diferencia de Debian, donde se restringen los permisos para cambiar paquetes a individuos o equipos). Los paquetes en Ubuntu deben tener por lo general el campo Maintainer como Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>. Si el campo del mantenedor se cambia, el valor anterior debe guardarse en XSBC-Original-Maintainer. Esto puede hacerse automticamente con el script update-maintainer que es parte del paquete ubuntu-dev-tools. Para obtener mayor informacin, vase la pgina Debian Maintainer Field spec en la wiki de Ubuntu. Cada prrafo adicional describe un paquete binario a ser construido. Para obtener mayor informacin, vase la seccin sobre el archivo de control (Captulo 5) del manual de normas de Debian.
2.2.3 El archivo copyright

Este archivo almacena la informacin de derechos de autor para ambos, el proyecto original y el empaquetado. Tanto Ubuntu como Debian en la seccin 12.5 de su manual de normas establecen que cada paquete debe instalar una copia literal del archivo de copyright y de la informacin del licenciamiento en /usr/share/doc/$(nombre_del_paquete)/copyright. Por lo general, la informacin sobre los derechos de autor se encuentra en el archivo COPYING dentro del directorio de cdigo fuente del programa. Este archivo debe contener informacin tal los nombres de los autores, del creador del paquete, la URL de donde sali el cdigo fuente y una lnea de Copyright con el ao, el titular de los derechos de autor y el propio texto del copyright. Una plantilla de ejemplo sera:
Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Upstream-Name: Hello Source: ftp://ftp.example.com/pub/games Files: * Copyright: Copyright 1998 John Doe <jdoe@example.com> License: GPL-2+ Files: debian/* Copyright: Copyright 1998 Jane Doe <packager@example.com> License: GPL-2+ License: GPL-2+
34
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. . This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. . You should have received a copy of the GNU General Public License along with this package; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA . On Debian systems, the full text of the GNU General Public License version 2 can be found in the file /usr/share/common-licenses/GPL-2.
Este ejemplo sigue el formato de Machine-readable debian/copyright (archivo debian/copyright legible por una mquina). Se le anima a usar este formato de la misma forma.
2.2.4 El archivo de reglas

El ltimo archivo que se necesita estudiar es el archivo rules. Este archivo hace todo el trabajo para crear el paquete. Es un Makele con secciones para compilar e instalar el programa, y despus crear el archivo .deb a partir de los archivos instalados. Tambin tiene una seccin para limpiar todos los archivos generados por la compilacin, con el n de volver a quedarse nicamente con el paquete fuente. Esta es una versin simplicada del archivo de reglas creado por dh_make (el cual se puede encontrar en el paquete dh-make):
#!/usr/bin/make -f # -*- makefile -*# Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 %: dh $@
Analicemos con ms detalle este archivo. Lo que hace es pasar cada seccin de compilacin invocada por debian/rules como un parmetro a /usr/bin/dh, que a su vez ejecutar todos los comandos dh_* necesarios. dh ejecuta una secuencia de rdenes de debhelper. Las secuencias soportadas son las que corresponden a las secciones del archivo debian/rules: build, clean, install, binary-indep, y binary. Para saber cuales son las rdenes que se ejecutan en cada seccin, ejecute:
$ dh binary-arch --no-act
A las rdenes de la secuencia binary-indep se incluye la opcin -i para asegurar que solo funcionen en paquetes binarios independientes, mientras que a las rdenes de la secuencia binary-arch se les agrega una opcin -a para asegurar que solo funcionen para paquetes independientes de la arquitectura.
35
Cada orden debhelper registrar cuando se ha ejecutado correctamente en debian/package.debhelper.log (archivo que dh_clean elimina). De esta manera dh puede saber qu rdenes ya han sido ejecutadas, para qu paquetes y evitar ejecutar esas rdenes de nuevo. Cada vez que dh se ejecuta, comprueba el registro y busca la ltima orden registrada que est en la secuencia especicada. Contina entonces con la siguiente orden de la secuencia. Las opciones --until, --before, --after y --remaining pueden modicar este comportamiento. Si el archivo debian/rules contiene una seccin con el nombre override_dh_command, cuando se llegue a esa orden en la secuencia, dh ejecutar esa seccin en lugar de la orden original. La seccin sobrescrita puede ejecutar entonces la orden con opciones adicionales, o ejecutar rdenes completamente diferentes en su lugar (tngase en cuenta que para usar esta caracterstica, se debera construir las dependencias con debhelper 7.0.50 o superior). Vase /usr/share/doc/debhelper/examples/ y man dh para ms ejemplos. Vase tambin la seccin sobre el archivo de reglas (seccin 4.9) del manual de normas de Debian.
2.2.5 Archivos adicionales

El archivo de instalacin El archivo install lo usa dh_install para instalar archivos en el paquete binario. Tiene dos casos de uso estndar: Para instalar archivos en el paquete que no son manejados por el sistema de compilacin del proyecto original. Partir paquete fuente en un nico chero grande en varios paquetes binarios. En el primer caso, el archivo install debera contener solo una linea por cada archivo instalado, indicando tanto el archivo como el directorio de destino. Por ejemplo, el siguiente archivo install instalara el script foo que se encuentra en la raz del paquete en usr/bin y el archivo desktop del directorio debian en usr/share/applications:
foo usr/bin debian/bar.desktop usr/share/applications
Cuando un paquete fuente crea varios paquetes binarios, dh instala los archivos en debian/tmp en lugar de debian/<paquete>. Los archivos instalados en debian/tmp pueden entonces moverse a diferentes paquetes binarios usando varios archivos $nombre_paquete.install. Esto se hace frecuentemente para separar grandes cantidades de datos que son independientes de la arquitectura de paquetes que dependen de la misma, llevndolos a paquetes Architecture: all. En este caso, solo se necesita el nombre de los archivos (o directorios) a instalar, sin el directorio de instalacin. Por ejemplo, un archivo foo.install que solo contenga archivos dependientes de la arquitectura se vera as:
usr/bin/ usr/lib/foo/*.so
Por el contrario, un archivo foo-common.install que solo contenga archivos que son independientes de la arquitectura se vera as:
/usr/share/doc/ /usr/share/icons/ /usr/share/foo/ /usr/share/locale/
Esto creara dos paquetes binarios, foo y foo-common. Ambos necesitaran su propia seccin en el archivo debian/control. Vase man dh_install y la seccin sobre el archivo install (Section 5.11) de la gua del nuevo mantenedor de Debian para obtener ms informacin. 2.2. Descripcin general bsica del Directorio debian/ 36
El archivo de avisos (watch) El archivo debian/watch permite comprobar automticamente si existe una nueva versin del proyecto original con la herramienta uscan, localizada en el paquete devscripts. La primera lnea del archivo watch debe describir la versin del formato (3, en el momento de escribir esto), mientras que el resto de lneas contienen las URLs a analizar. Por ejemplo:
version=3 http://ftp.gnu.org/gnu/hello/hello-(.*).tar.gz
Ejecutando uscan en el directorio raz del paquete comparar el nmero de versin original que se encuentra en debian/changelog con el ltimo disponible en el proyecto original. Si se encuentra una versin ms moderna del proyecto original, se descargar automticamente. Por ejemplo:
$ uscan hello: Newer version (2.7) available on remote site: http://ftp.gnu.org/gnu/hello/hello-2.7.tar.gz (local version is 2.6) hello: Successfully downloaded updated package hello-2.7.tar.gz and symlinked hello_2.7.orig.tar.gz to it
Si sus archivos tar residen en Launchpad, el archivo debian/watch es algo ms complicado (vase Question 21146 y Bug 231797 para saber por qu). En este caso, usamos algo como:
version=3 https://launchpad.net/flufl.enum/+download http://launchpad.net/flufl.enum/.*/flufl.enum-(.+).tar.gz
Para ms informacin, vase man uscan y la seccin sobre el archivo watch (seccin 4.11) del manual de normas de Debian. Para obtener una lista de los paquetes de los que el archivo watch informa no estar sincronizados con las versiones originales vase la pgina Ubuntu External Health Status (estado de salud externa de Ubuntu, en ingls). El archivo de formato (source/format) Este archivo indica el formato fuente del paquete. Solo debera contener una lnea indicando el formato deseado: 3.0 (native) para paquetes nativos de Debian (sin versin en upstream) 3.0 (quilt) para paquetes con un archivo tar de upstream independiente. 1.0 para paquetes que desean declarar explcitamente el formato por defecto Actualmente, el formato fuente del paquete ser por defecto 1.0 si no existe este archivo. Se puede establecer esto explcitamente en el archivo source/format. Si elige no usar este archivo para denir el formato, Lintian mostrar una advertencia sobre su ausencia. La advertencia es de carcter informativo y puede ser ignorada. Se le anima a utilizar el nuevo formato fuente 3.0 . Proporciona una serie de nuevas caractersticas: Soporte para formatos de compresin adicionales: bzip2, lzma y xz Soporte para varios archivos tar de upstream No es necesario volver a empaquetar los archivos tar de upstream para eliminar el directorio debian Los cambios especcos de Debian ya no se guardan en un nico archivo .diff.gz, sino en varios parches compatibles con quilt en debian/patches/ http://wiki.debian.org/Projects/DebSrc3.0 contiene informacin adicional concerniente a la migracin al formato de paquetes fuente 3.0.
37
Vase man dpkg-source y la seccin sobre el archivo source/format (seccin 5.21) de la gua del nuevo mantenedor de Debian para ms detalle.
2.2.6 Recursos adicionales

Adems de los enlaces hacia el manual de normas de Debian en cada seccin de arriba, la gua del nuevo mantenedor de Debian contiene descripciones ms detallas de cada archivo. El captulo 4 Archivos necesarios del directorio debian explica con mayor profundidad los archivos de control (control), de registro de cambios (changelog), de derechos de autor (copyright) y de reglas (rules). El captulo 5, Otros archivos dentro del directorio debian documenta archivos adicionales que podran utilizarse.
2.3 autopkgtest: pruebas automticas para paquetes

DEP 8 specication dene cmo se pueden integrar fcilmente pruebas automticas en los paquetes. Para integrar una prueba en un paquete, todo lo que necesita hacer es: aadir lo siguiente a la seccin Source de debian/control:
XS-Testsuite: autopkgtest
aadir un archivo de nombre debian/tests/control que especique los requisitos para el banco de pruebas, aadir las pruebas en debian/tests/.
2.3.1 Requisitos del banco de pruebas

En debian/tests/control se especica lo que se espera del banco de pruebas. As, por ejemplo, debe recoger todos los paquetes necesarios para las pruebas, si el banco de pruebas falla durante la compilacin o si hacen falta permisos de root.DEP 8 specication_ recoge todas las opciones disponibles. Ms adelante vamos a ver el paquete fuente glib2.0. En un caso muy simple el archivo podra tener la siguiente forma:
Tests: build Depends: libglib2.0-dev, build-essential
Para la prueba de debian/tests/build esto se asegurara que los paquetes libglib2.0-dev y build-essential estn instalados. Nota: Puede usar @ en la lnea Depends para indicar que desea que estn instalados todos los paquetes que son compilados por el paquete fuente en cuestin.
2.3.2 La prueba real

La prueba asociada al ejemplo anterior podra ser:
#!/bin/sh # autopkgtest check: Build and run a program against glib, to verify that the # headers and pkg-config file are installed correctly # (C) 2012 Canonical Ltd. # Author: Martin Pitt <martin.pitt@ubuntu.com>
2.3. autopkgtest: pruebas automticas para paquetes
38
set -e WORKDIR=$(mktemp -d) trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM cd $WORKDIR cat <<EOF > glibtest.c #include <glib.h> int main() { g_assert_cmpint (g_strcmp0 (NULL, "hello"), ==, -1); g_assert_cmpstr (g_find_program_in_path ("bash"), ==, "/bin/bash"); return 0; } EOF gcc -o glibtest glibtest.c pkg-config --cflags --libs glib-2.0 echo "build: OK" [ -x glibtest ] ./glibtest echo "run: OK"
Aqu una porcin de cdigo C muy simple se escribe en un directorio temporal. Luego es compilada con las bibliotecas del sistema (usando los marcadores y rutas de bibliotecas proporcionadas por pkg-cong). Luego el binario compilado, que simplemente prueba algunas partes de la funcionalidad del ncleo de glib, se ejecuta. Aunque esta prueba es muy pequea y bsica, prueba un buen nmero de componentes del sistema. Esto puede ayudar a descubrir de forma temprana incidencias crticas.
2.3.3 Ejecutando la prueba

El script de prueba se puede ejecutar fcilmente por s mismo, pero si quiere asegurarse de que el banco de pruebas est correctamente congurado, debera usar adt-run del paquete autopkgtest para ejecutarlo. La forma ms sencilla de hacerlo es ejecutar esta orden en el rbol fuente:
sudo adt-run --no-built-binaries --built-tree=. --- adt-virt-null
La desventaja de este enfoque es que se prueba en local, pero no puede asegurarse que vaya a funcionar en un entorno mnimo. Por ejemplo ser difcil asegurar que todos los paquetes requeridos estn instalados para las pruebas. Con lp:auto-package-testing contamos con una herramienta de pruebas ms completa. Esta utiliza una mquina virtual totalmente limpia para realizar las pruebas. Para su conguracin, en primer lugar instale las dependencias necesarias:
sudo apt-get install qemu-utils kvm eatmydata
Luego, obtenga el cdigo fuente desde Launchpad:

bzr branch lp:auto-package-testing cd auto-package-testing
Y disponer de un sistema Saucy AMD64:

./bin/prepare-testbed -r saucy amd64
Esta orden crear una MV de Saucy AMD64 completamente limpia, a partir de una imagen de la nube. Para correr las pruebas, simplemente ejecute:
2.3. autopkgtest: pruebas automticas para paquetes
39
./bin/run-adt-test -r saucy -a amd64 \ -S file:///tmp/glib2.0-2.35.7/ glib2.0
Esto usara el paquete fuente de /tmp/glib2.0-2.35.7/ y ejecutara las pruebas de este rbol contra el paquete glib2.0 del archivo. La opcin -S tambin 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 instalarn los binarios resultantes de esa compilacin. Esto es til si quiere ejecutar las pruebas sobre una versin ms moderna que la empaquetada en Ubuntu, o si el paquete no est en absoluto en Ubuntu. Si usa el marcador -k puede iniciar sesin en la mquina virtual despus de que se completen las pruebas. Esto hace que sea muy sencillo depurar los problemas. auto-package-testing documentation contiene mucha ms informacin valiosa sobre otras opciones de prueba.
2.3.4 Ms ejemplos
Esta lista no es completa, pero podra ayudarle a hacer una mejor idea de cmo estn implementadas y cmo se usan las pruebas automatizadas en Ubuntu. libxml2 tests son muy parecidos. Tambin realizan una generacin de una prueba a partir de una porcin de cdigo C sencilla y la ejecutan. gtk+3.0 tests tambin realiza una comprobacin de compilacin/enlace/ejecucin en la prueba build. Hay una prueba adicional python3-gi que verica que la biblioteca GTK es accesible tambin mediante introspeccin. En ubiquity tests se ejecuta en conjunto de pruebas de aguas arriba. gvfs tests realiza pruebas exhaustivas de su funcionalidad y son muy interesantes porque emulan el uso de CDs, Samba, DAV y otras cosas.
2.3.5 Infraestructura de Ubuntu

Los paquetes que tienen activado autopkgtest ejecutarn sus pruebas siempre que se suban o cambie alguna de sus dependencias. La salida de automatically run autopkgtest tests se puede ver en la web y se actualiza de forma regular. Aunque Debian no tiene todava una infraestructura de pruebas automticas, se deberan enviar igualmente a Debian, ya que DEP-8 es una especicacin de Debian y sus desarrolladores o usuarios pueden ejecutar las pruebas manualmente. Los paquetes en Debian con una cabecera de conjunto de pruebas tambin sern aadidos automticamente cuando se sincronicen con Ubuntu.
2.3.6 Llevando la prueba a Ubuntu

El proceso de enviar un autopkgtest para un paquete es muy parecido a xing a bug in Ubuntu. En esencia debe simplemente: ejecutar bzr branch ubuntu:<packagename>, editar el archivo debian/control para activar las pruebas, aadir el directorio debian/tests. escribir el debian/tests/control basado enDEP 8 Specication_, aadir sus casos de prueba a debian/tests, conrmar los cambios, empujarlos a Launchpad, proponer una integracin y hacer que la revisen igual que cualquier otra mejora de un paquete fuente. 2.3. autopkgtest: pruebas automticas para paquetes 40
2.3.7 Lo que puede hacer

El equipo de ingeniera de Ubuntu ha preparado una lista de casos de prueba requeridos, donde los paquetes que necesitan pruebas se colocan en diferentes categoras. Aqu puede encontrar ejemplos de esas pruebas y asignarlas fcilmente a usted. Si encuentra algn problema, puede unirse al canal de IRC #ubuntu-quality para ponerse en contacto con desarrolladores que pueden ayudarle.
2.4 Obtener el cdigo fuente

2.4.1 URLs de los paquetes fuente
Bazaar proporciona varios atajos muy buenos para acceder a las ramas fuentes de paquetes de Launchpad tanto de Ubuntu como de Debian. Para referirse a las ramas fuentes use:
ubuntu:package
donde paquete se reere el nombre del paquete en el que est interesado. Esta URL se reere al paquete en la versin de desarrollo actual de Ubuntu. Para referirse a la rama de Tomboy en la versin de desarrollo, debera usar:
ubuntu:tomboy
Para referirse a la versin de un paquete fuente de una versin ms antigua de Ubuntu, aada al nombre del paquete el prejo con el cdigo de nombre de la versin. Por ejemplo, para referirse al paquete fuente de Tomboy en Maverick use:
ubuntu:maverick/tomboy
Puesto que son nicos, tambin puede abreviar el nombre de las series de distribuciones:
ubuntu:m/tomboy
Puede usar un esquema similar para acceder a las ramas fuentes de Debian, aunque en este caso no hay atajos para nos nombres de las series de distribuciones de Debian. Para acceder a la rama de Tomboy en la serie de desarrollo de Debian actual use:
debianlp:tomboy
y para acceder a Tomboy en Debian Lenny use:

debianlp:lenny/tomboy
2.4.2 Obtener el cdigo fuente

Cada paquete fuente de Ubuntu tiene asociada una rama fuente en Launchpad. Estas ramas fuentes son actualizadas automticamente por Launchpad, aunque el proceso actualmente no es infalible. Hay un par de cosas que se hacen antes para que el ujo de trabajo posterior sea ms eciente. Una vez que se acostumbre al proceso aprender cuando puede saltarse estos pasos.
2.4. Obtener el cdigo fuente
41
Crear un repositorio compartido Digamos que desea trabajar en el paquete Tomboy, y que ha comprobado que el paquete fuente se llama tomboy. Antes de efectuar la bifurcacin del cdigo de Tomboy, cree un repositorio compartido para mantener las ramas de este paquete. Este repositorio compartido har que el trabajo futuro sea mucho ms eciente. Hgalo usando la orden bzr init-repo, pasndole el nombre de directorio que le gustara usar:
$ bzr init-repo tomboy
Ver que se crea un directorio tomboy en su rea de trabajo actual. Cambie a este nuevo directorio para el resto del proceso:
$ cd tomboy
Obtener la rama troncal Se usa la orden bzr branch para crear una rama local del paquete. Llamaremos al directorio destino tomboy.dev slo para mantenerlo fcil de recordar:
$ bzr branch ubuntu:tomboy tomboy.dev
El directorio tomboy.dev representa la versin de Tomboy en la versin de desarrollo de Ubuntu y siempre puede cambiarse (cd) a este directorio y hacer bzr pull para obtener actualizaciones futuras. Asegurarse de que la versin est actualizada Cuando hace bzr branch obtendr un mensaje indicndole si la rama de empaquetado est actualizada. Por ejemplo:
$ bzr branch ubuntu:tomboy Most recent Ubuntu version: 1.8.0-1ubuntu1.2 Packaging branch status: CURRENT Branched 86 revisions.
Ocasionalmente el importador falla y las ramas de empaquetado no coincidirn con lo que hay en el repositorio. Un mensaje diciendo:
Packaging branch status: OUT-OF-DATE
signica que el importador ha fallado. Puede averiguar por qu en http://package-import.ubuntu.com/status/ y presentar un error en el proyecto le a bug on the UDD project para hacer que se resuelva la incidencia. Tar aguas arriba (upstream) Puede obtener un tar de aguas arriba ejecutando:
bzr get-orig-source
Esto probar varios mtodos para obtener el archivo tar de aguas arriba, primero recrendolo desde la etiqueta upstream-x.y del archivo bzr, luego descargndolo desde el repositorio de Ubuntu y nalmente ejecutando debian/rules get-orig-source. El tar de aguas arriba tambin se recrear cuando se usa bzr para construir el paquete:
bzr builddeb
El complemento builddeb tiene varias opciones de conguracin conguration options. 2.4. Obtener el cdigo fuente 42
Obtener una rama de una versin en particular Cuando desee hacer algo como una stable release update (SRU, actualizacin de versin estable) o si simplemente quiere examinar el cdigo de una versin antigua, deber obtener la rama correspondiente a una versin de Ubuntu en particular. Por ejemplo, para obtener el paquete de Tomboy para Maverick haga:
$ bzr branch ubuntu:m/tomboy maverick
Importar un paquete fuente de Debian Si el paquete en el que desea trabajar est disponible en Debian, pero no en Ubuntu, sigue siendo fcil importar el cdigo a una rama de bzr local para el desarrollo. Digamos que quiere importar el paquete fuente newpackage. Empezaremos por crear un repositorio compartido como habitualmente, pero tambin debemos crear un rbol de trabajo en el que importar el paquete fuente (recuerde salir del directorio tomboy creado anteriormente):
$ $ $ $ $ bzr init-repo newpackage cd newpackage bzr init debian cd debian bzr import-dsc http://ftp.de.debian.org/debian/pool/main/n/newpackage/newpackage_1.0-1.dsc
Como puede ver, solo hace falta proporcionar la ubicacin remota del archivo dsc, y Bazaar har el resto. Ya ha obtenido la rama fuente de Bazaar.
2.5 Trabajar en un paquete

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 emisin a la que tiene pensado subirlo. Normalmente se trata de la emisin actualmente en desarrollo, pero podran ser tambin emisiones anteriores si est adaptando cambios a un SRU, por ejemplo.
2.5.1 Bifurcar para hacer un cambio

Lo primero a hacer es asegurarse de que su rama del paquete fuente est actualizada. Lo estar si la acaba de extraer, de otra forma haga lo siguiente:
$ cd tomboy.dev $ bzr pull
Todas las actualizaciones al paquete que se hayan subido desde que realiz la extraccin se descargarn 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 correccin del error de la siguiente forma:
$ bzr branch tomboy.dev bug-12345 $ cd bug-12345
Ahora puede hacer todo el trabajo en el directorio bug-12345. Puede hacer ah los cambios que considere necesarios, conrmndolos segn avance. Esto es lo mismo que realizar cualquier desarrollo de software con Bazaar. Puede hacer conrmaciones parciales tan frecuentes como desee y cuando haya terminado con los cambios, usar la orden estndar dch (del paquete devscripts):
2.5. Trabajar en un paquete
43
$ dch -i
Esto le dejar en un editor para que aada una entrada al archivo debian/changelog. Cuando aadi su entrada en el archivo debian/changelog debera haber incluido una etiqueta de correccin 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 nmero del error real que ha corregido. Su entrada de debian/changelog podra tener el siguiente aspecto:
tomboy (1.5.2-1ubuntu5) natty; urgency=low * Dont fubar the frobnicator. (LP: #12345) -- Bob Dobbs <subgenius@example.com> Mon, 10 Jan 2011 16:10:01 -0500
Conrmar con el habitual:

bzr commit
Un enganche en bzr-builddeb usar el texto de debian/changelog como mensaje de conrmacin y usar la etiqueta para marcar el bug #12345 como corregido. Esto solo funciona con bzr-builddeb 2.7.5 y bzr 2.4. Para versiones ms antiguas use debcommit.
2.5.2 Construir el paquete

Por el camino querr compilar su rama de forma que pueda probarla y asegurarse de que realmente corrige el error. Para de construir el paquete se puede utilizar la orden bzr builddeb del paquete bzr-builddeb. Se puede construir un paquete fuente con:
$ bzr builddeb -S
(bd es un alias de builddeb). Se puede dejar el paquete sin rmar aadiendo -- -uc -us a la orden. Tambin es posible utilizar sus herramientas habituales, siempre que sean capaces de eliminar los directorios .bzr del paquete, por ejemplo:
$ debuild -i -I
Si en algn momento encuentra un error al intentar construir un paquete nativo sin un archivo tar, compruebe si existe un archivo .bzr-builddeb/default.conf que errneamente especique el paquete como nativo. Si la versin del changelog incluye un guin, no se trata de un paquete nativo, as que elimine el archivo de conguracin. Tenga en cuenta que aunque bzr builddeb tiene un indicador --native, no dispone de un indicador --no-native. Una vez haya obtenido el paquete fuente, puede construirlo de forma normal con pbuilder-dist (o pbuilder o sbuild).
2.6 Buscar revisor y patrocinador

Una de las ventajas ms importantes de usar el ujo de trabajo de UDD es mejorar la calidad buscando revisiones de cambios de sus compaeros. Esto es cierto tenga usted o no permisos para subir cdigo. Por supuesto, si no tiene permisos para subir, necesitar buscar un patrocinio. Una vez que est satisfecho con su correccin 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 integracin para que otros la revisen y que los patrocinadores la suban.
2.6. Buscar revisor y patrocinador
44
2.6.1 Empujar a Launchpad

Anteriormente le hemos mostrado cmo asociar su rama al error (associate your branch to the bug) 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. No es crtico tener un enlace a un error para cada cambio que realice, pero si est corrigiendo errores reportados enlazarlos es til. La forma genera del URL a la que debera empujar su rama es:
lp:~<user-id>/ubuntu/<distroseries>/<package>/<branch-name>
Por ejemplo, para empujar su correccin del error 12345 en el paquete Tomboy para Natty, usara:
$ bzr push lp:~subgenius/ubuntu/natty/tomboy/bug-12345
El ltimo componente de la ruta es arbitrario; depende de usted elegir algo signicativo. Sin embargo, esto no es normalmente suciente para que los desarrolladores de Ubuntu revisen y patrocinen su cambio. Debera envar una propuesta de integracin. Para hacerlo, abra la pgina del error en un navegador, por ejemplo:
$ bzr lp-open
Si eso falla, puede usar:

$ xdg-open https://code.launchpad.net/~subgenius/ubuntu/natty/tomboy/bug-12345
donde la mayora de los URL coincidan con las que ha usado para bzr push. En esta pgina, ver un enlace que dice Propose for merging into another branch (proponer para ser integrada en otra rama). Escriba una explicacin de su cambio en la casilla Initial Comment (comentario inicial). Finalmente, pulse Propose Merge (proponer integracin) para completar el proceso. Las propuestas de integracin a ramas de paquetes fuente subscribirn automticamente al equipo ~ubuntu-branches, lo que debera ser suciente para que lleguen a un desarrollador de Ubuntu que pueda revisar y patrocinar sus cambios al paquete.
2.6.2 Generar un debdiff

Como se ha indicado anteriormente, algunos patrocinadores todava preeren revisar un archivo debdiff adjunto al informe de error en lugar de una propuesta de integracin. Si se le pide que incluya un debdiff, puede generar uno de esta forma (desde dentro de su rama del error bug-12345):
$ bzr diff -rbranch:../tomboy.dev
Otra forma es abrir una propuesta de integracin y descargar las diferencias (diff). Debera asegurarse de que diff tiene los cambios que espera, ni ms, ni menos. D un nombre apropiado al diff, por ejemplo foobar-12345.debdiff y adjntelo al informe de error.
2.6.3 Tratar los comentarios de los patrocinadores

Si un patrocinador revisa su rama y le pide que cambie algo, puede hacerlo de forma bastante sencilla. Simplemente vaya a la rama en la que estaba trabajando anteriormente, haga los cambios solicitados, y luego confrmelos:
$ bzr commit
2.6. Buscar revisor y patrocinador
45
Ahora, cuando empuje su rama a Launchpad, Bazaar recordar donde la ha empujado y actualizar la rama de Launchpad con sus ltimos cambios conrmados. Todo lo que necesita hacer es:
$ bzr push
Puede entonces responder al correo de revisin de la propuesta de integracin explicando lo que ha cambiado y pidiendo que se vuelva a revisar o puede responder en la pgina de la propuesta de integracin en Launchpad. 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 adjuntndolo al informe de error.
2.6.4 Expectativas
Los desarrolladores de Ubuntu han preparado una planicacin 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 das hasta que tenga respuesta. Esto depende de lo ocupado que est todo el mundo, y si la emisin en desarrollo est ya congelada u otros factores. 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. Para ms informacin sobre el proceso de patrocinio general, revise la documentacin de nuestro wiki tambin: https://wiki.ubuntu.com/SponsorshipProcess
2.7 Subir un paquete

Una vez que su propuesta de integracin 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). Tambin es posible que desee realizar una subido si est patrocinando los cambios de otra persona.
2.7.1 Subir un paquete que ha modicado

Cuando tenga una rama con cambios que le gustara subir tendr que llevar esos cambios de vuelta a la rama de cdigo principal, compilar el paquete fuente y luego subirlo. Primero necesita comprobar que dispone de la ltima versin del paquete en su extraccin de la rama troncal del paquete de desarrollo:
$ cd tomboy/tomboy.dev $ bzr pull
Esto descarga todos los cambios que se hayan podido conrmar mientras ha estado trabajando en su correccin. A partir de este punto tiene varias opciones. Si los cambios en la rama troncal son importantes y considera que deberan probarse junto con sus cambios puede fusionarlos en su rama de correccin del error y probarlos ah. Si no lo son, puede continuar integrando sus rama de correccin 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 estndar.
$ bzr merge ../bug-12345
Para versiones ms antigas de bzr, puede usar en su lugar la orden merge-package:

$ bzr merge-package ../bug-12345
2.7. Subir un paquete
46
Esto fusionar los dos rboles, posiblemente produciendo conictos, que deber resolver manualmente. Despus debera asegurarse de que el archivo debian/changelog est como desea, con la distribucin correcta, nmero de versin, etc. Una vez realizado deberia revisar el cambio que est a punto de conrmar con bzr diff. Esto debera mostrarle los mismos cambios que devolvera debdiff antes de que suba el paquete fuente. El siguiente paso es construir y probar el paquete fuente como hara normalmente:
$ bzr builddeb -S
Cuando por n est satisfecho con su rama, asegrese de haber conrmado todos los cambios y luego etiqutela con el nmero de versin del registro de cambios (changelog). La orden bzr tag lo har por usted de forma automtica cuando no se le pasen parmetros:
$ bzr tag
Esta etiqueta le dir al importador del paquete que lo que est en la rama de Bazaar es lo mismo que lo que est en el repositorio. Ahora ya puede empujar los cambios de vuelta a Launchpad:
$ bzr push ubuntu:tomboy
(cambie el destino si est subiendo una SRU o similar). 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 ubicacin apropiada. Por ejemplo, si quiere subir sus cambios a su PPA, debera hacer:
$ dput ppa:imasponsor/myppa tomboy_1.5.2-1ubuntu5_source.changes
o, si tiene permisos para subir al repositorio primario:

$ dput tomboy_1.5.2-1ubuntu5_source.changes
Ahora ya puede borrar su rama, ya que se ha integrado, y se puede volver a descargar de Launchpad si hiciera falta.
2.7.2 Patrocinar un cambio

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 integracin.
$ bzr merge lp:~subgenius/ubuntu/natty/tomboy/bug-12345
Si hay muchos conictos en la integracin probablemente desee pedirle al contribuyente que los arregle. Vea la siguiente seccin para aprender cmo cancelar una integracin pendiente. Pero si los cambios tienen buena pinta, confrmelos y luego siga el resto del proceso de subida:
$ bzr commit --author "Bob Dobbs <subgenius@example.com>"
2.7.3 Cancelar una descarga

En cualquier momento antes de haga dput del paquete fuente puede decidir cancelar una subida y deshacer los cambios:
$ bzr revert
Puede hacerlo si nota que algo necesita ms trabajo o si le gustara pedir a un contribuyente que arregle conictos cuando est patrocinando algo. 2.7. Subir un paquete 47
2.7.4 Patrocinar algo y hacer sus propias modicaciones

Si va a patrocinar el trabajo de otra persona, pero a la vez le gustara aadir algunos cambios suyos puede hacerlo fusionando antes ambos trabajos en una rama independiente. 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 extraccin del paquete de desarrollo. Puede entonces hacer los cambios y conrmarlos y seguir con sus cambios al paquete. Si no tiene una rama existente, pero sabe que desea hacer cambios en base a lo proporcionado por el contribuyente, debera entonces comenzar por obtener su rama:
$ bzr branch lp:~subgenius/ubuntu/natty/tomboy/bug-12345
luego trabaje en esta nueva rama, intgrela en la principal y sbala como si fuera su propio trabajo. Todava se mencionar al contribuyente en el registro de cambios (changelog) y Bazaar le atribuir correctamente los cambios que realiz.
2.8 Obtener lo ltimo

Si alguien ms ha introducido cambios en un paquete, desear descargarse esos cambios en su propia copia de las ramas de paquetes.
2.8.1 Actualizar su rama principal

Actualizar su copia de una rama que se corresponda con el paquete en una versin particular es muy sencillo, simplemente use bzr pull desde el directorio apropiado:
$ cd tomboy/tomboy.dev $ bzr pull
Esto funciona cuando ha realizado una extraccin de una rama, as que funcionar para ramas como maverick, hardyproposed, etc.
2.8.2 Obtener lo ltimo en sus ramas de trabajo

Una vez que haya actualizado su copia de una rama de una serie de la distribucin, puede que desee fusionarlo en sus ramas de trabajo tambin, de forma que estn basadas en el cdigo ms reciente. Sin embargo no tiene por qu hacer esto todo el tiempo. Puede trabajar con cdigo ligeramente ms antiguo sin problemas. La desventaja vendra si estuviera trabajando en algn cdigo que alguien ms ya haya cambiado. Si no est trabajando con la versin ms reciente sus cambios puede que no sean correctos e incluso pueden producir conictos. Sin embargo, la integracin debe realizarse en algn punto. Cuando ms se retrase, ms complicado puede ser, as que realizarlo de forma regular debera hacer que cada integracin sea sencilla. Incluso si hay muchas fusiones el esfuerzo total sera afortunadamente menor. Para fusionar los cambios solo necesita usar bzr merge, pero debe haber conrmado su trabajo actual antes:
$ cd tomboy/bug-12345 $ bzr merge ../tomboy.dev
Se reportarn todos los conictos y podr solucionarlos. Para revisar los cambios que acaba de fusionar use bzr diff. Para deshacer el cambio use bzr revert. Cuando est satisfecho con los cambios use bzr commit. 2.8. Obtener lo ltimo 48
2.8.3 Referirse a versiones de un paquete

Frecuentemente pensar en trminos de versiones de un paquete, en lugar de nmeros de versin subyacentes de Bazaar. bzr-builddeb proporciona un especicador de revisin que hace que sea prctico. Cualquier orden que incluya un parmetro -r para especicar una revisin o un rango de revisiones funcionar con este especicador, como por ejemplo bzr log, bzr diff y otros. Para ver la versin de un paquete, use el especicador package::
$ bzr diff -r package:0.1-1..package:0.1-2
Esto le mostrar la diferencia entre las versiones de los paquetes 0.1-1 y 0.1-2.
2.9 Combinar Actualizar desde Debian y desde aguas arriba (Upstream)

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 revisin 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 1 . Mientras se encuentre en el directorio de trabajo de una rama, puede integrar una rama desde una ubicacin diferente. Primero compruebe que no tiene cambios sin conrmar:
$ bzr status
Si eso le reporta cualquier cosa, entonces tendr que conrmar los cambios, revertirlos o dejarlos de lado para volver ms tarde.
2.9.1 Fusionar desde Debian

Despus ejecute bzr merge pasndole la URL de la rama desde la que fusionar. Por ejemplo, para fusionar desde la versin del paquete de Debian Unstable_ ejecute:
$ bzr merge lp:debian/tomboy
Esto fusionar los cambios desde el ltimo punto de integracin y le dejar con cambios para revisar. Esto puede provocar algunos conictos. Puede ver todo lo que la orden merge realiz ejecutando:
$ bzr status $ bzr diff
Si se reportan conictos necesitar editar esos archivos para que se vean como deben, eliminando los marcadores de conicto. Una vez que lo haya realizado, ejecute:
$ bzr resolve $ bzr conflicts
Esto resolver todos los archivos conictivos que haya corregido y luego le dir qu ms tiene hacer. Una vez resueltos los conictos y de que haya realizado los cambios que crea oportunos, deber aadir una entrada en el registro de cambios (changelog) y realizar la conrmacin:
$ dch -i $ bzr commit
1 Para comprobar otras ramas disponibles de un paquete en Debian, visite la pgina de cdigo del paquete. Por ejemplo, https://code.launchpad.net/debian/+source/tomboy
2.9. Combinar Actualizar desde Debian y desde aguas arriba (Upstream)
49
como se describi anteriormente. Sin embargo, antes de realizar la conrmacin, siempre es conveniente comprobar todos los paquetes de Ubuntu ejecutando:
$ bzr diff -r tag:0.6.10-5
lo que le mostrar las diferencias entre las versiones Debian (0.6.10-5) y Ubuntu (0.6.10-5ubuntu1). De forma similar puede comparar cualquier otras versiones. Para ver todas las versiones disponibles ejecute:
$ bzr tags
Despus de probar y conrmar la fusin, necesitar buscar un patrocinador o subirlo al repositorio de la forma habitual. Si va a construir el paquete fuente desde la rama fusionada, debera usar la opcin -S en la orden bd. Otra cosa que querr tener en cuenta es usar la opcin --package-merge. Esto aadir las opciones -v y -sa adecuadas al paquete fuente de forma que todas las entradas del registro de cambios (changelog) desde el ltimo cambio de Ubuntu se incluyan en su archivo _source.changes. Por ejemplo:
$ bzr builddeb -S --package-merge
2.9.2 Integrar una nueva versin de aguas arriba

Cuando aguas arriba se libera una nueva versin (o quiere empaquetar una instantnea), tendr que integrar un archivo tar en su rama. Eso se hace mediante la orden bzr merge-upstream. Si su paquete tiene un archivo debian/watch vlido, desde dentro de la rama en la que quiere realizar la integracin, escriba simplemente:
$ bzr merge-upstream
Esto descargar el tar y lo integrar en su rama, aadiendo automticamente por usted una entrada en debian/changelog. bzr-builddeb busca en el archivo debian/watch la ubicacin del archivo tar de aguas arriba. Si no dispone de un archivo debian/watch necesitar indicar la ubicacin del archivo tar de aguas arriba y la versin manualmente:
$ bzr merge-upstream --version 1.2 http://example.org/releases/foo-1.2.tar.gz
La opcin --version se usa para especicar la versin de aguas arriba que se est integrando, ya que la orden no es capaz de deducirlo (de momento). El ltimo parmetro es la ubicacin del archivo tar al que se est actualizando; puede ser una ruta local de su sistema de archivos o una URI http, ftp, sftp, etc. como se muestra. La orden descargar automticamente el archivo tar por usted. La orden merge-upstream le dir si se ha ejecutado con xito o si aparecieron conictos. En cualquiera de los casos podr revisar los cambios antes de conrmarlos como siempre. Si est integrando una emisin de aguas arriba en una rama Bazaar existente que no ha usado anteriormente la distribucin de UDD, bzr merge-upstream fallar con un error indicando que la etiqueta de la versin anterior de aguas arriba no est disponible; la integracin no se puede completar sin conocer contra qu versin base hacerlo. Para solventar el problema, cree una etiqueta en su repositorio para la ltima versin de aguas arriba ah presente; por ejemplo, si la ltima emisin de Ubuntu fue 1.1-0ubuntu3, cree la etiqueta upstream-1.1 apuntando a la revisin bzr que desea que se use como punta de la rama de aguas arriba.
2.9. Combinar Actualizar desde Debian y desde aguas arriba (Upstream)
50
2.10 Usar chroots

Si ejecuta una versin de Ubuntu pero trabaja en paquetes de otra versin, puede crear un ambiente para esa otra versin con un chroot Un chroot le permite tener un sistema de archivos completo de otra distribucin el cual puede funcionar normalmente. Esto evita la sobrecarga de ejecutar una maquina virtual
2.10.1 Crear un chroot

Use la orden debootstrap para crear un nuevo chroot:
$ sudo debootstrap oneiric oneiric/
Esto crear el directorio oneiric e instalar un sistema mnimo en l. Si su versin de debootstrap no reconoce oneiric puede intentar la actualizacin a la versin en backports. Puede trabajar dentro del chroot:
$ sudo chroot oneiric
Dnde puede instalar o eliminar cualquier paquete que desee sin afectar a su sistema principal. Quizs quiera copiar sus claves GPG/ssh y su conguracin de Bazaar dentro del chroot de manera que pueda acceder y rmar paquetes directamente:
$ sudo mkdir oneiric/home/<username> $ sudo cp -r ~/.gnupg ~/.ssh ~/.bazaar oneiric/home/<username>
Para detener apt y otros programas que se quejan por la perdida de locales, puede instalar el paquete de idioma correspondiente:
$ apt-get install language-pack-en
Si quiere correr programas X necesita enlazar el directorio /tmp dentro del chroot, desde fuera del chroot ejecute:
$ sudo mount -t none -o bind /tmp oneiric/tmp $ xhost +
Algunos programas pueden necesitar vincularse a /dev o /proc. Para ms informacin sobre chroot revise la pgina de wiki Debootstrap Chroot wiki page
2.10.2 Alternativas
Sbuild es un sistema similar a Pbuilder para crear entornos donde pueda ejecutar pruebas de construccin de paquetes. Es ms parecido al utilizado por Launchpad para construir paquetes pero lleva ms tiempo congurarlo comparado con Pbuilder. Veas the Security Team Build Environment wiki page para obtener una explicacin ms detallada. La virtualizacin completa de mquinas puede ser til para el empaquetado y prueba de programas. TestDrive es un programa para automatizar la sincronizacin y ejecucin de imgenes ISO, revise la pgina wiki de TestDrive para ms informacin. Puede congurar pbuilder para hacer una pausa cuando encuentre un error en la construccin. Copie C10shell desde /usr/share/doc/pbuilder/examples en un directorio y use el parmetro --hookdir= para apuntar a l.
2.10. Usar chroots
51
EC2 cloud computers de Amazon le permite contratar a un equipo pagando unos pocos centavos de dlar por hora, puede congurar mquinas Ubuntu de cualquier versin compatible y empaquetar en ellas. Esto es til cuando se desea compilar varios paquetes al mismo tiempo o para superar las limitaciones de ancho de banda.
2.11 Empaquetado tradicional

La mayor parte de esta gua trata del desarrollo distribuido de Ubuntu (Ubuntu Distributed Development (UDD)) que emplea el sistema de control de versiones distribuido (DVCS) Bazaar para obtener los paquetes fuentes ( retrieving package sources) y enviar correcciones con propuestas de integracin (merge proposals.). Esta artculo explicar lo que denominamos mtodos de empaquetado tradicional, a falta de una palabra mejor. Antes de que se adoptara Bazaar para el desarrollo de Ubuntu estos eran los mtodos tpicos para contribuir a Ubuntu. En algunos casos, puede que necesite estas herramientas en lugar de UDD. As que es recomendable estar familiarizado con ellas. Antes de que comience, debera haber ledo ya el artculo sobre la preparacin de la conguracin en Getting Set Up.
2.11.1 Obtener el cdigo fuente

Para obtener un paquete fuente, puede simplemente ejecutar:
$ apt-get source <package_name>
Este mtodo, sin embargo, tiene algunos inconvenientes. Descarga la versin del cdigo fuente que est disponible en su sistema. El probable que est corriendo la emisin estable actual, pero que desee contribuir su cambio contra el paquete de la versin en desarrollo. Afortunadamente, el paquete ubuntu-dev-tools le proporciona un asistente:
$ pull-lp-source <package_name>
De forma predeterminada, se descargar la ltima versin de la emisin en desarrollo. Puede tambin indicar una versin o emisin de Ubuntu como:
$ pull-lp-source <package_name> precise
para extraer el cdigo fuente de la emisin precise o:

$ pull-lp-source <package_name> 1.0-1ubuntu1
para descargar la versin 1.0-1ubuntu1 del paquete. Para ms informacin sobre la orden, vase man pull-lp-source. Para nuestro ejemplo, vamos a suponer que tenemos un informe de error que dice que el colour en la descripcin de xicc debera ser color y deseamos corregirlo (tenga en cuenta que esto es slo un ejemplo de algo a cambiar y no un error de verdad). Para obtener el cdigo fuente, ejecute:
$ pull-lp-source xicc 0.2-3
2.11.2 Crear un Debdiff

Un archivo debdiff muestra las diferencias entre dos paquetes Debian. El nombre de la orden empleada para generarlo tambin se llama debdiff. Es parte del paquete devscripts. Vese man debdiff para obtener toda la informacin. Para comparar dos paquetes fuentes, pase los dos archivos dsc como parmetros:
2.11. Empaquetado tradicional
52
$ debdiff <package_name>_1.0-1.dsc <package_name>_1.0-1ubuntu1.dsc
Para continuar con nuestro ejemplo, edite el archivo debian/control y corrija el error:
$ cd xicc-0.2 $ sed -i s/colour/color/g debian/control
Debemos cumplir tambin con la especicacin de campo del mantenedor de Debian (Debian Maintainer Field Spec) y editar el archivo debian/control para reemplazar:
Maintainer: Ross Burton <ross@debian.org>
con:
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com> XSBC-Original-Maintainer: Ross Burton <ross@debian.org>
Puede usar la herramienta update-maintainer (del paquete ubuntu-dev-tools) para hacerlo. Recuerde documentar sus cambios en debian/changelog usando dch -i tras lo cual ya se puede generar un nuevo paquete fuente:
$ debuild -S
Ahora ya puede examinar los cambios usando debdiff:

$ cd .. $ debdiff xicc_0.2-3.dsc xicc_0.2-3ubuntu1.dsc | less
Para crear un archivo de parche que pueda enviar a otros o adjuntando a un informe de error para su patrocinio, ejecute:
$ debdiff xicc_0.2-3.dsc xicc_0.2-3ubuntu1.dsc > xicc_0.2-3ubuntu1.debdiff
2.11.3 Aplicar un Debdiff

Para aplicar un debdiff, primero asegrese de que tiene el cdigo fuente de la versin para la que se cre:
$ pull-lp-source xicc 0.2-3
Luego, en un terminal, entre en el directorio en el que se ha descomprimido el fuente:

$ cd xicc-0.2
Un debdiff es igual que un archivo de parche normal. Aplquelo de la forma habitual con:
$ patch -p1 < ../xicc_0.2.2ubuntu1.debdiff
2.12 Empaquetar mdulos y aplicaciones de Python

Nuestro empaquetado sigue la Python policy de Debian. Usaremos el paquete python-markdown como ejemplo, el cual se puede descargar desde PyPI. Puede ver su empaquetado en su Subversion repository. Existen dos tipos de paquetes de Python: mdulos y aplicaciones. En el momento de escribir esto, Ubuntu tiene dos versiones incompatibles de Python: 2.x y 3.x. /usr/bin/python es un enlace simblico a la versin Python 2.x predeterminada y /usr/bin/python3, a la versin Python 3.x predeterminada. Los mdulos de Python se deberan construir contra todas las versiones de Python soportadas.
2.12. Empaquetar mdulos y aplicaciones de Python
53
Si va a empaquetar un nuevo mdulo Python, encontrar la herramienta py2dsc til (disponible en el paquete pythonstdeb).
2.12.1 debian/control
Las versiones Python 2.x y 3.x del paquete deberan estar en paquetes binarios separados. Los nombres deberan tener el formato python{,3}-modulename (como: python3-dbus.mainloop.qt). Aqu usaremos python-markdown y python3-markdown para los paquetes del mdulo y python-markdown-doc para el paquete de documentacin. Elementos de debian/control que son especcos para los paquetes Python: La seccin de los paquetes de mdulos debera ser python y doc para el paquete de documentacin. Para una aplicacin, un simple paquete binario ser suciente. Deberan aadirse dependencias de compilacin a python-all (>= 2.6.6-3~) y python3-all (>= 3.1.2-7~) para asegurarse de que los asistentes de Python estn disponibles (vase la siguiente seccin para ms detalles). Se recomienda aadir los campos X-Python-Version y X-Python3-Version, vase la seccin Specifying Supported Versions de la poltica para ms informacin. Por ejemplo:
X-Python-Version: >= 2.6 X-Python3-Version: >= 3.1
Si su paquete funciona slo con Python 2.x o 3.x, la compilacin depende solo de un paquete -all y usa solo un campo -Version. Los paquetes de mdulos deberan tener variables de sustitucin {python3:Depends} (respectivamente) en sus listas de dependencias. {python:Depends} y
2.12.2 debian/rules
Los asistentes recomendados para mdulos python son dh_python2 y dh_python3. Desafortunadamente, debhelper no compila todava paquetes Python 3.x automticamente (vase bug 597105 en Debian BTS), as que deber hacerlo manualmente en las secciones override (omita esto si su paquete no soporta Python 3.x). Aqu tiene nuestro archivo debian/rules (con anotaciones):
# These commands build the list of supported Python 3 versions # The last version should be just python3 so that the scripts # get a correct shebang. # Use just PYTHON3 := $(shell py3versions -r) if your package # doesnt contain scripts PY3REQUESTED := $(shell py3versions -r) PY3DEFAULT := $(shell py3versions -d) PYTHON3 := $(filter-out $(PY3DEFAULT),$(PY3REQUESTED)) python3 %: # Adding the required helpers dh $@ --with python2,python3 override_dh_auto_clean: dh_auto_clean rm -rf build/ override_dh_auto_build: # Build for each Python 3 version
54
set -ex; for python in $(PYTHON3); do \ $$python setup.py build; \ done dh_auto_build override_dh_auto_install: # The same for install; note the --install-layout=deb option set -ex; for python in $(PYTHON3); do \ $$python setup.py install --install-layout=deb --root=debian/tmp; \ done dh_auto_install
Tambin es una buena prctica ejecutar pruebas durante la compilacin, si se distribuyen desde aguas arriba. Normalmente las pruebas se pueden invocar usando setup.py test o setup.py check.
2.12.3 debian/*.install
Los mdulos de Python .x se instalan en el directorio /usr/share/pyshared/ y se crean enlaces simblicos en /usr/lib/python2.x/dist-packages/ para cada versin del intrprete, mientras que los de Python 3.x se instalan en /usr/lib/python3/dist-packages/. Si su paquete es una aplicacin y tiene mdulos de Python privados, debera instalarse en /usr/share/module o en /usr/lib/module si los mdulos son dependientes de la arquitectura (por ejemplo, extensiones). Vase la seccin de programas que incluyen mdulos privados (Programs Shipping Private Modules) de la poltica. As que nuestro archivo python-markdown.install se parecer a esto (tambin queremos instalar un ejecutable markdown_py):
usr/lib/python2.*/ usr/bin/
y python3-markdown.install tendr nicamente una lnea:

usr/lib/python3/
2.12.4 El paquete -doc

La herramientas ms comnmente usada para compilar documentos Python es Sphinx, Para aadir documentacin Sphinx a su paquete (usando el asistente dh_sphinxdoc), debera: Aadir una dependencia de compilacin a python-sphinx o a python3-sphinx (dependiendo de la versin de Python que desee usar); Aadir sphinxdoc a la lnea dh --with; Ejecutar setup.py build_sphinx en override_dh_auto_build (en ocasiones no es necesario); Aadir {sphinxdoc:Depends} a la lista de dependencias de su paquete -doc; Aadir la ruta del directorio de generacin de documentacin (normalmente build/sphinx/html) a su archivo .docs. En nuestro caso, los documentos se compilan automticamente en el directorio build/docs/ cuando ejecutamos setup.py build, as que podemos simplemente ponerlo en el archivo python-markdown-doc.docs:
build/docs/
55
Puesto que docs tambin contiene archivos fuente .txt, tambin le indicaremos a dh_compress que no los comprima, aadiendo lo siguiente a debian/rules:
override_dh_compress: dh_compress -X.txt
2.12.5 Comprobar errores de empaquetado

Junto con lintian, hay una herramienta especial para comprobar paquetes Python, lintian4py. Est disponible en el paquete lintian4python. Por ejemplo, estas dos rdenes invocan a las dos versiones de lintian y comprueban los paquetes fuentes y binarios:
lintian -EI --pedantic *.dsc *.deb lintian4py -EI --pedantic *.dsc *.deb
Aqu la opcin -EI se usa para activar etiquetas experimentales e informativas.
2.12.6 Vea tambin

Python policy; Python/Packaging, artculo en la wiki de Debian; Python/LibraryStyleGuide y Python/AppStyleGuide, artculos en la wiki de Debian; Los equipos python-modules y python-apps de Debian.
2.13 Empaquetado de KDE

El empaquetado de programas de KDE en Ubuntu se gestiona por los equipos de Kubuntu y MOTU. Puede contactar con el equipo de Kubuntu en Kubuntu mailing list (lista de correo de Kubuntu) y en el canal de IRC de Freenode #kubuntu-devel. Puede encontrar ms informacin sobre el desarrollo de Kubuntu en la pgina wiki Kubuntu wiki page. Nuestro empaquetado sigue las directrices de los equipos Debian Qt/KDE y Debian KDE Extras. La mayora de nuestros paquetes se derivan del empaquetado de estos equipos de Debian.
2.13.1 Poltica de parches

Kubuntu no aade parches a los programas KDE a menos que vengan de los autores aguas arriba o se hayan enviado aguas arriba con la expectativa de que sean combinados pronto o hayamos consultado la incidencia con los autores aguas arriba. Kubuntu no cambia la marca de los paquetes excepto cuando aguas arriba esperan que se haga (por ejemplo, el logotipo de la parte inferior izquierda del men de inicio) o para simplicar (por ejemplo, eliminar las pantallas iniciales).
2.13.2 debian/rules
Los paquetes de Debian incluyen algunos aadidos al uso bsico de Debhelper. Estos aadidos se mantienen en el paquete pkg-kde-tools. Los paquetes que usan Debhelper 7 deberan aadir la opcin --with=kde. Esto asegurar que se usan los marcadores de compilacin adecuados y que se aaden opciones como la gestin de los stubs de kdeinit y las traducciones:
2.13. Empaquetado de KDE
56
%: dh $@ --with=kde
Algunos paquetes ms modernos de KDE usan el sistema dhmk, una alternativa a dh desarrollada por el equipo QT/KDE de Debian. Puede leer sobre el mismo en /usr/share/pkg-kde-tools/qt-kde-team/2/README. Los paquetes que lo usen incluirn include /usr/share/pkg-kde-tools/qt-kde-team/2/debian-qt-kde.mk en lugar de ejecutar dh.
2.13.3 Traducciones
Las traducciones de los paquetes de main en se importan en Launchpad y se exportan de Launchpad a los paquetes de idiomas de Ubuntu. As que todos los paquetes de main de KDE deben generar plantillas de traduccin, incluir o hacer disponibles aguas arriba las traducciones y gestionar los archivos .desktop de traducciones. Para generar las plantillas de traduccin el paquete debe incluir un archivo Messages.sh; qujese aguas arriba si no lo hace. Puede comprobar si funciona ejecutando extract-messages.sh lo que debera producir uno o ms archivos .pot en el directorio po/. Esto se har automticamente durante la compilacin si usa la opcin --with=kde de dh. Normalmente aguas arriba ya habrn puesto tambin los archivos de traducciones .po en el directorio po/. Si no lo han hecho, compruebe si estn aguas arriba en paquetes de idiomas separados, como los paquetes de idiomas de KDE SC. Si lo estn Launchpad necesitar asociarlos de forma manual. Contacte con dpm para hacerlo. Si un paquete se mueve desde universe a main tendr que ser vuelto a subir antes de que las traducciones se importen en Launchpad. Los archivos .desktop tambin necesitan traducciones. Se parchea KDELibs para que lea las traducciones de los archivos .po que estn apuntados por una lnea X-Ubuntu-Gettext-Domain= aadida a los archivos .desktop en el momento de compilar el paquete. Se genera un archivo .pot para cada paquete en el momento de la compilacin y los archivos .po necesarios se descargan desde aguas arriba y se incluyen en el paquete o en los paquetes de idiomas. La lista de archivos .po a descargar de los repositorios de KDE est en /usr/lib/kubuntu-desktop-i18n/desktop-template-list.
2.13.4 Smbolos de biblioteca

Los smbolos de biblioteca se rastrean en archivos .symbols para asegurarse de que no falta ninguno para las nuevas emisiones. KDE usa bibliotecas C++ que actuan de forma ligeramente diferente a como lo hacen las de C. El equipo Qt/KDE de Debian dispone de scripts para gestionarlo. Vase Working with symbols les (trabajar con archivos de smbolos) para saber cmo crear y mantener actualizados estos archivos.
2.13. Empaquetado de KDE
57
CAPTULO 3
Lecturas adicionales
Puede leer esta gua sin conexin en diferentes formatos, si instala uno de los paquetes binarios. Si quiere conocer ms sobre la construccin de paquetes Debian, aqu tiene algunos recursos Debian que pueden resultarle tiles: Cmo empaquetar para Debian; Manual de polticas de Debian; Gua de los nuevos mantenedores de Debian disponible en muchos idiomas; Tutorial de empaquetado (tambin disponible como un paquete).
58

Ubuntu Packaging Guide

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Ubuntu Packaging Guide

Transféré par

Droits d'auteur :

Formats disponibles

Ubuntu Packaging Guide

Release 0.3.3 bzr403 quantal1

Ubuntu Packaging Guide, Release 0.3.3 bzr403 quantal1

1.1 Introduccin al desarrollo de Ubuntu

Ubuntu Packaging Guide, Release 0.3.3 bzr403 quantal1

1.1. Introduccin al desarrollo de Ubuntu

Ubuntu Packaging Guide, Release 0.3.3 bzr403 quantal1

de revisiones de cdigo y sucientes discusiones.

1.2 Fase de preparacin

1.2. Fase de preparacin

Ubuntu Packaging Guide, Release 0.3.3 bzr403 quantal1

1.2.1 Instalar software bsico de empaquetado

1.2. Fase de preparacin

Ubuntu Packaging Guide, Release 0.3.3 bzr403 quantal1

1.2. Fase de preparacin

Ubuntu Packaging Guide, Release 0.3.3 bzr403 quantal1

1.2.2 Preparar una conguracin para trabajar con Launchpad

y le mostrar algo como:

1.2. Fase de preparacin

Ubuntu Packaging Guide, Release 0.3.3 bzr403 quantal1

Ahora guarde el archivo y reinicie su terminal o ejecute:

1.2. Fase de preparacin

Ubuntu Packaging Guide, Release 0.3.3 bzr403 quantal1

1.3 Desarrollo distribuido de Ubuntu (Ubuntu Distributed Development, UDD) Introduccin

1.3.1 Limitaciones del empaquetado tradicional

1.3.2 Desarrollo distribuido de Ubuntu

1.3. Desarrollo distribuido de Ubuntu (Ubuntu Distributed Development, UDD) Introduccin 9

Ubuntu Packaging Guide, Release 0.3.3 bzr403 quantal1

1.3. Desarrollo distribuido de Ubuntu (Ubuntu Distributed Development, UDD) Introduccin 10

Ubuntu Packaging Guide, Release 0.3.3 bzr403 quantal1

1.3.4 Limitaciones del UDD

1.3. Desarrollo distribuido de Ubuntu (Ubuntu Distributed Development, UDD) Introduccin 11

Ubuntu Packaging Guide, Release 0.3.3 bzr403 quantal1

1.4 Corregir un fallo en Ubuntu

1.4.2 Encontrar el problema

1.4.3 Averiguar qu se debe corregir

1.4. Corregir un fallo en Ubuntu

Ubuntu Packaging Guide, Release 0.3.3 bzr403 quantal1

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

apt-cache es parte de la instalacin estndar de Ubuntu.

1.4.4 Obtener el cdigo

1.4.5 Trabajar en una solucin

1.4.6 Probar la solucin

1.4. Corregir un fallo en Ubuntu

Ubuntu Packaging Guide, Release 0.3.3 bzr403 quantal1

1.4. Corregir un fallo en Ubuntu

Ubuntu Packaging Guide, Release 0.3.3 bzr403 quantal1

Un ejemplo podra ser:

1.5 Tutorial: corregir un error en Ubuntu

1.5.1 Conrmar el problema

La salida debera ser algo parecido a esto:

1.5. Tutorial: corregir un error en Ubuntu

Ubuntu Packaging Guide, Release 0.3.3 bzr403 quantal1

Un contraejemplo sera gedit, el cual tiene denida una pgina web:

1.5.2 Investigar la situacin de un error

1.5.3 Ofrecer ayuda

1.5. Tutorial: corregir un error en Ubuntu

Ubuntu Packaging Guide, Release 0.3.3 bzr403 quantal1

1.5.4 Corregir la incidencia

debera ver algo como esto:

1.5.5 Documentar la solucin

y ver algo como esto:

1.5. Tutorial: corregir un error en Ubuntu

Ubuntu Packaging Guide, Release 0.3.3 bzr403 quantal1