Ubuntu logo

Packaging Guide

4. Corrigindo um erro no Ubuntu

4.1. Introdução

Se você seguiu as instruções do prepare-se para o Desenvolvimento do Ubuntu, você deve estar pronto para começar.

./_images/fixing-a-bug.png

Como você pode observar na imagem acima, não há surpresas no processo de correção de erros no Ubuntu: você encontra um problema, obtém o código, trabalha para corrigi-lo, testa, envia as alterações para o Launchpad e pede para que sejam revisadas e incorporadas. Neste guia nós passaremos por todas as etapas necessárias, uma por uma.

4.2. Encontrando o problema

Há várias maneiras diferentes de encontrar coisas nas quais trabalhar. Pode ser um relatório de erro que você mesmo encontrou (o que lhe dá uma boa oportunidade para testar a correção), ou um problema que você encontrou em outro lugar, talvez num relatório de erro.

Harvest é onde podemos seguir as várias listas de afazeres relacionadas ao desenvolvimento do Ubuntu. Ele lista erros que já foram corrigidos no upstream ou no Debian, lista pequenos erros (que chamamos de “bitezise”), e assim por diante. Confira o site e encontre o seu primeiro bug para trabalhar.

4.3. Descobrindo o que corrigir

Se você não sabe qual o pacote fonte que contém o código que tem o problema, mas você sabe o caminho para o programa afetado no seu sistema, você pode descobrir o pacote fonte no qual você precisa trabalhar.

Digamos que você tenha encontrado um erro no Tomboy, um aplicativo para tomar notas na área de trabalho. O Tomboy pode ser iniciado executando “/usr/bin/tomboy” na linha de comando. Para encontrar o pacote binário que contém esse aplicativo, use este comando:

$ apt-file find /usr/bin/tomboy

Isso deverá imprimir:

tomboy: /usr/bin/tomboy

Note que a parte que precede o ponto-e-vírgula é o nome do pacote binário. Frequentemente, o pacote fonte e o pacote binário terão nomes diferentes. Isto é mais comum quando um único pacote fonte é utilizado para construir diferentes pacotes binários. Para encontrar o pacote fonte de um pacote binário em particular, digite:

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

apt-cache é parte da instalação padrão do Ubuntu.

4.4. Obtendo o código

Uma vez que você saiba em qual pacote fonte trabalhar, você deverá obter uma cópia do código para o seu sistema, para que você possa depurá-lo. No Desenvovimento distribuído do Ubuntu, isto é feito ramificando o ramo do pacote fonte correspondente ao pacote fonte. O Launchpad mantém ramos de pacotes fontes para todos os pacotes do Ubuntu.

Once you’ve got a local branch of the source package, you can investigate the bug, create a fix, and upload your proposed fix to Launchpad, in the form of a Bazaar branch. When you are happy with your fix, you can submit a merge proposal, which asks other Ubuntu developers to review and approve your change. If they agree with your changes, an Ubuntu developer will upload the new version of the package to Ubuntu so that everyone gets the benefit of your excellent fix - and you get a little bit of credit. You’re now on your way to becoming an Ubuntu developer!

Nós vamos descrever especificações sobre como ramificar um código, enviar sua correção e solicitar uma revisão nas próximas seções.

4.5. trabalhar em uma correção

Há livros inteiros escritos sobre encontrar erros, corrigi-los, testá-los, etc. Se você for um programador novato, tente corrigir erros fáceis primeiro, como erros de digitação óbvios. Tente alterar o mínimo possível, e documente sua alteração e suposições com clareza.

Antes de trabalhar na correção você mesmo, tenha certeza de investigar se ninguém já corrigiu ou está trabalhando na correção para a falha. Boas fontes para verificar são:

  • Rastreamento de erros upstream (e Debian) de erros abertos e fechados,

  • Histórico de revisão do upstream (ou lançamento recente) poderia ter corrigido o problema,

  • bugs ou envio de pacotes do Debian ou outras distribuições.

Você agora quer criar um patch que inclui a correção. O comando edit-patch é um caminho fácil para adicionar um patch em um pacote. Execute:

$ edit-patch 99-new-patch

Isso copiará o empacotamento para um diretório temporário. Agora você pode editar arquivos com um editor de textos ou aplicar patches do upstream, por exemplo:

$ patch -p1 < ../bugfix.patch

Após editar o tipo de arquivo exit ou pressione control-d para sair do shell temporário. O novo patch será adicionado em debian/patches.

4.6. Testando a correção

Para construir um pacote de teste com suas alterações, e execute estes comandos:

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

Isto irá criar um pacote fonte a partir do conteúdo do ramo (“-us -uc” irá apenas omitir o passo para assinar o pacote fonte) e “pbuilder-dist” irá construir o pacote a partir da fonte para qualquer “versão” que você escolher.

Uma vez que a construção for concluída, instale o pacote do ~/pbuilder/<lançamento>_result/ (usando sudo dpkg -i <pacote>_<versão>.deb). Então teste para ver se a falha está corrigida.

4.6.1. Documentando a correção

É muito importante documentar a sua alteração suficientemente de maneira que os desenvolvedores que olharem o código no futuro não terão que adivinhar qual foi o seu raciocínio e quais foram a suposições. Todo pacote fonte do Debian e do Ubuntu inclui o “debian/changelog”, onde alterações em cada pacote enviado são rastreadas.

A maneira mais fácil de atualizar isto é executar:

$ dch -i

Isto irá adicionar um modelo entrada de registro de alteração para você e iniciar um editor onde você possa preencher os espaços em branco. Um exemplo disso poderia ser:

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

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

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

dch should fill out the first and last line of such a changelog entry for you already. Line 1 consists of the source package name, the version number, which Ubuntu release it is uploaded to, the urgency (which almost always is ‘low’). The last line always contains the name, email address and timestamp (in RFC 5322 format) of the change.

Com isso fora do caminho, vamos nos concentrar na entrada do registro de alteração propriamente dita: é muito importante documentar:

  1. onde a alteração foi realizada

  2. o que foi alterado

  3. onde a discussão da mudança aconteceu

In our (very sparse) example the last point is covered by (LP: #123456) which refers to Launchpad bug 123456. Bug reports or mailing list threads or specifications are usually good information to provide as a rationale for a change. As a bonus, if you use the LP: #<number> notation for Launchpad bugs, the bug will be automatically closed when the package is uploaded to Ubuntu.

4.6.2. Submetendo uma correção

Com a entrada escrita e salva no registro de mudanças, você pode apenas executar:

debcommit

e a mudança será submetida (localmente) com sua entrada no registro de mudanças como uma mensagem de submissão.

Para enviar ele para o Launchpad, como um nome de ramo remoto, você precisa manter a seguinte nomenclatura:

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

Isto poderia por exemplo ser:

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

Então se apenas você executar:

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

você deve estar preparado. O comando push deve enviá-lo ao Launchpad e o segundo comando irá abrir a página do Launchpad do ramo remoto no seu navegador. Lá, encontre o link “(+) Propose for merging”, clique nele para que a alteração seja revisada por alguém e incluída no Ubuntu.

Nosso artigo sobre buscando orientação entra em mais detalhes sobre a obtenção de retorno para as suas alterações propostas.

Se o seu ramo corrigir problemas em uma versão estável ou for uma correção de segurança, você pode querer dar uma olhada no nosso artigo Atualizações de segurança e de versões estáveis.