Since I use a lot my main computer, I install there pbuilder/devs tools/virtualbox to modify packages for the development cycle, I only use my test machine for packages that require real hardware to be tested. So, the first thing I do when a new cycle starts is create a new directory for the cycle that is starting, precise for this example.

$ mkdir -pv misc/ubuntu/ubuntu-12.04 && cd misc/ubuntu/ubuntu-12.04
$ mkdir  -pv app  diffs  isos  merge  udw

I mantain my ubuntu related stuff with this hierarchy:

$ tree -L 2 misc/ubuntu
 ├── results/
 │   ├── lucid-amd64/
 │   ├── lucid-i386/
 │   ├── maverick-i386/
 │   ├── natty-i386/
 │   ├── oneiric-i386/
 │   └── sid-i386/
 ├── ubuntu-10.04/
 │   ├── app/
 │   ├── diffs/
 │   ├── isos/
 │   ├── merge/
 │   └── udw/
 ├── ubuntu-10.10/
 │   ├── app/
 │   ├── diffs/
 │   ├── isos/
 │   ├── merge/
 │   └── udw/
 ├── ubuntu-11.04/
 │   ├── app/
 │   ├── diffs/
 │   ├── isos/
 │   ├── merge/
 │   └── udw/
 └── ubuntu-11.10/
 ├── app/
 ├── diffs/
 ├── isos/
 ├── merge/
 └── udw/

Which can be disassemble it as follows:

results => contains the output of pbuilder (.debs ready to been tested), I’ve added a patch to copy the packages keeping my ID as the owner

ubuntu-version => which contains everything related to that version, isos, packages (FTBFS), udw logs, diffs (which are actually debdiffs, this is the classic format to send patches), and merges

Once the dirs have been created, I check the latest versions of some devs packages (ubuntu-dev-tools, ubuntu-qa-tools & ubuntu-security-tools)

$ bzr branch lp:ubuntu-dev-tools ~/misc/ubuntu/tools/ubuntu-dev-tools
$ bzr get \
  http://bazaar.launchpad.net/~ubuntu-bugcontrol/ubuntu-qa-tools/master \
  ~/misc/ubuntu/tools/ubuntu-qa-tools
$ bzr branch lp:ubuntu-security-tools \
  ~/misc/ubuntu/tools/ubuntu-security-tools

With those tools under my fingers I can start downloading the last isos (to test them), I do this as soon as possible, and then I keep upgrading it once a week, I use the $ ./dl-ubuntu-test-iso script who comes with the ubuntu-qa-tools package. Before I run it I edit the ~/.dl-ubuntu-test-iso file, currently it looks like this, the parts that I change is RELEASE=”precise” and ISOROOT=”/home/chilicuil/misc/ubuntu/ubuntu-12.04/isos/” I only download the desktop | server and netbook versions, however the VARIANTS and FLAVORS variables can be edited to download more images. It will run faster if zsync is installed

$ cd ~/misc/ubuntu/tools/ubuntu-qa-tools/dl-ubuntu-test-iso && \
  ./dl-ubuntu-test-iso &

The next thing I do is to set up pbuilder, I’ve already wrote about it, so I’ll just point out what variables I modify in ~/.pbuilder, for each new release I change the UBUNTU_SUITES var:

UBUNTU_SUITES=(“oneiric” “natty” “lucid“) => UBUNTU_SUITES=(“precise” “oneiric” “natty” “lucid“)

And add the aliases to ~/.bashrc:

alias pbuilder.precise=’sudo DIST=precise pbuilder’

I also modify the /etc/bash_completion.d/pbuilder to get autocompletion:

[ "$have" ] && complete -F _pbuilder -o filenames pbuilder pbuilder.lucid pbuilder.maverick pbuilder.natty pbuilder.oneiric pbuilder.precise pbuilder.sid pbuilder.unstable

The complete file is here, finally I run:

$ pbuilder.precise create

To obtain the precise environment where packages would be build

http://www.flickr.com/photos/67103741@N07/show/

I’m running Ubuntu lucid (10.04 also known as the LTS version), and I only had to:

#download the source

$ bzr branch lp:ubuntu-packaging-guide

#install sphinx ( http://sphinx.pocoo.org/ )

$ sudo apt-get install python-sphinx

#produce the documentation

$ make html #or make latexpdf, check the Makefile out for more options

I know nothing about sphinx but looking at the files I suppose the *.rst are whom produce the files…

Still no idea how to get the .deb package from it, but thanks to tumbleweed from #ubuntu-motu to show me how simple getting the docs actually was >_>’ (even without the .deb package), i10n is still in progress at mainstream

Not a lot had happened for me, the alpha group is having a lot of more comments, but still not sure if it’s having the success it was suppose to have, the final iso testing for natty has been started, the oneiric (the next ubuntu version) topics also have started, the newletters seems dead, people talked about unity till the last minute…

The blogs I keep reading and that I really, really recommend are:

http://raphaelhertzog.com/

http://daniel.holba.ch/blog/

…going back to what people call ‘reality’ =(

The Ubuntu BugSquad Mentorship group α is a class of mentors and students.

This is a test-pilot run during the Natty cycle to see whether mentoring new bug triagers in a group, having several mentors and a mailing list will improve the results of the BugSquad Mentorship program.

Rcart and me have enrolled ourselves, if you wanna join the initiative just send a message to ubuntu-bugsquad AT lists.ubuntu.com, since it’s a restricted group right now. Not a lot of messages have been interchanged yet, let’s see how it grows up.

Like the author says:

About this tutorial
Goal: tell you what you really need to know about Debian packaging
Tries to keep a reasonable size
No attempt to be complete
You might need to read more documentation

Download at: www.webupd8.org

In this occasion, we’ll patch the bittornado package. (More info about BitTornado here)

Launchpad bug report
Debian bug report

So, here’s what we’ll do:

1. Creating the patch from scratch.
2. Apply upstream’s (debian) patch.

Creating the patch from scratch

First of all, we need to understand the bug report; what’s the problem and what’s the solution.

So, as we can read in the bug report, the problem it’s about deprecated sha module. The solution is to replace it with hashlib module. (More information here)

To start, we need to get BitTornado’s branch. But before that, we need to set a working directory and then we’ll be ready to work:
$ bzr branch lp:ubuntu/bittornado

Then, we need to create a branch starting from the original one:
$ bzr branch bittornado bittornado.fix-420387

And now it’s time to get down to work. What we firstly need, is to create a quilt patch (I hope that you know this patches system, BUT, if someone (if there’s someone over here xD) ask for a quick tutorial we’ll gladly give it to you ^^).

It’s recommended that we take a look at the patches naming under debian/patches directory, thus we can get an idea of what name use for our patch. So, the bug report patch’s name looks pretty good, and we’ll use it (following the numbering):
$ quilt new 32_use_hashlib_for_sha.patch

Then, find the python scripts that use the deprecated sha module and add them to our new patch. This can be achieved with the find and grep commands:
$ find . -path ./.pc -prune -o -name '*.py' | xargs grep 'from sha import'

In the above expression, we search in all the python scripts, skipping the files under .pc (applied patches), for the string “from sha import” and we’ll get an output like this:

./btshowmetainfo.py:from sha import *
./btrename.py:from sha import *
./btdownloadgui.py:from sha import sha
./btdownloadheadless.py:from sha import sha
./BitTornado/__init__.py:from sha import sha
./BitTornado/download_bt1.py:from sha import sha
./BitTornado/parsedir.py:from sha import sha
./BitTornado/BT1/Rerequester.py:from sha import sha
./BitTornado/BT1/makemetafile.py:from sha import sha
./BitTornado/BT1/track.py:from sha import sha
./BitTornado/BT1/StorageWrapper.py:from sha import sha
./BitTornado/BTcrypto.py:from sha import sha
./btdownloadcurses.py:from sha import sha

So, we need to extract from the result the files name, and then, add them to the patch, and we can do that with this:
$ find . -path ./.pc -prune -o -name '*.py' | xargs grep 'from sha import' | awk -F ":" '{print $1}' | xargs quilt add

From now on, quilt will be tracking our files for changes, and when we write the changes, it’ll generate the patch.

What we need now, is to edit the files and correct the bug. We have two choices:

1. Go for the files one by one and correct them
2. Files have same bug, use an expression for all of them

Well, the easiest way is to use an expression, and to achieve this we’ll use find, grep, awk and sed. I’ve built an expression like this:
$ find . -path ./.pc -prune -o -name '*.py' | xargs grep 'from sha import' | awk -F ":" '{print $1}' | xargs sed -i 's/from sha import sha/from hashlib import sha1 as sha/'

With that, we’ll edit all the bug files, but not the two files that had ‘*’ because they do not fit the sed arguments. So, is not difficult edit them and we will do it manually by changing:

from sha import sha *

To

from hashlib import sha1 as sha

Now, we’re ready to write the changes and get the patch:
$ quilt refresh

After that, we can visualize in the debian/patches directory our patch. That’s all about the patch, it’s time to edit the changelog:
$ dch -i

Here, we’ll increase the ubuntu revision and change the distribution version to natty (the actual development version), also create and entry specifying our changes. This is my changelog entry (thanks to ari-tczew for correcting it):

* debian/patches/32_use_hashlib_for_sha.patch:
– Updated use of deprecated sha module to hashlib. (LP: #420387)

— Ronny Cardona (Rcart) Mon, 24 Jan 2011 17:27:47 -0600

After save the changes, we need to add the quilt patch that we have created to our local branch, clean up the local branch by removing all applied patches, and then just miss commit the changes.
$ bzr add debian/patches/32_use_hashlib_for_sha.patch
$ quilt pop -a
$ bzr commit

We can leave as the commit message, the changelog entry.

Well, until here we have our patch ready to be applied, now we need to create the package’s source code, build the package and test it to confirm that our patch works correctly.

Create the package source code (for a gpg signed package):
$ bzr bd -- -S

And then, depending on our pbuilder configuration, build the package:
$ cd ../ ; pbuilder-dist natty build *.dsc

The package is finished, tested and the changes are correctly confirmed. So, let’s upload it to Launchpad, and afterward, we will request to be Proposed for Merge
$ bzr push lp:~rcart/ubuntu/natty/bittornado/fix-420387
$ bzr lp-open

In firefox (or whatever web browser that we have) click on “Propose for Merge“

And we can now wait for a reviewer member to sponsor our branch.

Apply Upstream bug report patch

This patch differs with the above, in that this uses exception handling and it’s safer.

The process is almost the same, difference is that we’ll not edit the files directly, instead we’ll use patch utility to edit them with an existing patch.

Get the branch, create a branch starting from the original one and enter to it.

Then, copy and save the patch code in a file (ending with .patch extension) to the parent working directory (../). Create a new quilt patch (the name of the patch from scratch is okay), find the bug files, add them to quilt patch, and then run:
$ patch -p1 -i ../patchname.patch

The above will correct the bug files by inserting the Debian patch. Now, write the patch:
quilt refresh

Update changelog file:
$ dch -i

Add the new patch to the local branch:
$ bzr add debian/patches/32_use_hashlib_for_sha.patch

Pop out the applied patches:
quilt pop -a

Commit the changes (use the changelog entry):
$ bzr commit

Now, create the source package, build it with pbuilder, test it and confirm that patch works. If all with building was fine, then upload it to LP:
$ bzr push lp:~rcart/ubuntu/natty/bittornado/fix-420387

Open LP and propose it for merge ;)
$ bzr lp-open

That’s all!

DEP3 is a Debian proposal to set embedded information in patches. It’ll help us to get information while reviewing patches; about the patch itself, author(s), origin, upstream related stuff, etc.

This information is used by some tools like Debian’s Patch Tracking System to display it.

The official site and information resource: http://dep.debian.net/deps/dep3/

DEP3 Tag requires some key fields, but not all of them are normally needed (all depends of the patch itself, the bug status and, somebody told me, the project size). Also, we must follow some rules in those key fields.

I’ll show you a simple dep3 tag patch, and I’ll explain the used fields. But first, let’s explain the patch and bug status:

• There’s a Launchpad Bug report with a patch
• There’s an upstream bug report with it’s respective patch
• We will use the upstream patch

So, keep in mind that in an after post, we’ll patch the above bug report package. But this is just a DEP3 Tag patch example:

From: Ronny Cardona (Rcart) <rcart1019@gmail.com>
Description: Updated use of deprecated sha module to hashlib.
Origin: http://bugs.debian.org/593653#17
Bug-Debian: http://bugs.debian.org/593653

Here starts the diff code
…..

From (or Author): The patch author
Description: A non-so long Description of what the patch does, ending with a dot, and using dot to split two paragraph. We can use the Subject field for a briefer description.
Origin: This patch it’s from upstream, so, i must explicitly signalize from where I’ve found it.
Bug-Debian: Like the bug it’s reported in upstream, here should be the Debian bug report address. Otherwise, (using Bug-Ubuntu) should be LP bug report address (a little bit doubtful about this, please confirm it in the website).

This tag must be placed in the patch head, and these are some rules that must be follow:

• Description field must end with a dot (.)
• If the patch is not yours, you must specify where comes from, in the Origin tag
• If it’s possible, put a shorter address
• There must be an empty new line between the patch tag and the diff code

So, with these little indications added to our patches, we can distribute them as Debian suggests.

I’ll document here my personal MOTU journey (too), in a, hopefully, understandable English.

In company with chilicuil, we’ll try to make 2 or 3 post every week, to registry our activities related with packaging and bugs in Ubuntu. We hope that these registries help others with the same intention, Become A Master Of The Universe.

Related posts:

• http://viajemotu.wordpress.com/2010/08/06/como-arreglar-bugs-con-bzr-version-corta/
• http://viajemotu.wordpress.com/2010/08/14/parchando-paquetes-con-quilt-bzr/

Regresando al tema y en vista de las pocas visitas de este blog, sí como esta escrito en el ‘sobre’ este espacio es principalmente para mi propia documentación, pero igual me entristese  ver que la comunidad latinoamericana no tiene interes por el empaquetamiento =(, asi que de ahora en adelante, intentare escribir las entradas en español/ingles, con preferencia a este último.

Por que no lo hice desde el principio?, hay varias razones, primero porque hay muy poca documentación en español, sino puedo generarla por el momento, al menos traducir las cosas que iba ocupando me parecio buena idea, luego tambien porque queria darle mas familiaridad al asunto, los tipos que se encargan de esto no son unos super genios, son gente normal como tu o yo.  Lo primero que probablemente deje de traducir seran los logs de los canales, eso me tomaba muchisimo tiempo y energia, aunque si llegara a recibir un solo comentario al respecto lo aria con gusto (que no venga del enfermo de ronicardona -.-).

Todas las faltas de ortografia/gramatica/coherencia que encuentren por fa, no sean gachos, comentemelas.

============================================================

This week, I tried to plug-in myself again after a while without reading anything MOTU related, I wanna send greetings to the i.am and go.to team, thx for making my life a peace of crap, only assh**** cut services a few hours before going offline, thx again!, my ass had never been so exposed to the air =)

Back to the topic and seeing that this blogs has so few visits, yes as I’ve already written in the ‘about’ section, this blog is mainly for my own pleasure but it’s still sad to see that the latin american comunity has to interest in packaging =(, so from now on I’ll write my entries in spanish/english giving preference to the second one.

Why I hadn’t done it from the beginning? there are several reasons, first because there is a lack of documentation in spanish so I thought, If I cannot write it I will translate the material I read. Second, to make it look more familiar, the guys who make this possible (the MOTU team) aren’t super genius, it’s normal people like you and me and last but not least my English truly SUCKS!

The first stuff I’ll stop translating will be the ubuntu logs, they take a lot of time and energy and aren’t viewed nor commented, so I think nobody cares about them, of course I can be in a mistake, so if someone finds them useful, just leave a comment and I’ll be happy to translate them again (except if that person is ronicardona -.-)

A last word, if you find any mistake in the orthography/grammar/consistency please leave a comment that way I could improve my English and you’ll have a huge THANK YOU!

============================================================

http://raphaelhertzog.com/

Llegue aqui a partir de un articulo de el ubuntu newsletter (si no las leido, sugiero que lo hagas), es el blog personal de Raphaël Hertzog, un desarrollador de debian con una especial atencion a escribir articulos para usuarios que deseen convertirse en desarrolladores ,no he leido todas sus entradas, pero lo que he hecho me ha gusto, te puedes inscribir para recibir sus actualizaciones por correo,

I came here because of an article of the amazing ubuntu newsletter (if you haven’t read it, don’t doubt to checking it out), it’s the personal blog of Raphaël Hertzog, a debian developer who likes writing posts for users who want to become developers, I’ve read all his entries, but the posts I’ve read so far are good, people can subscribe to receive updates by email.

http://askubuntu.com/search?q=motu

Nada, impresionante fuente de respuestas, para ser sincero creo que contestan mas rapido que en launchpad, me gusta el hecho de que desarrolladores y MOTU’s se tomen el tiempo para contestar. No he podido evitar ver informacion hay sobre lo que me interesa. La pregunta de ‘maco’ es en particular inspiradora.

An amazing source of answers, to be honest I think it’s faster that launchpad, one thing I really like is that developers and MOTU’s go and give an answer to ‘normal people’, I couldn’t stop myself from querying the database. The ‘maco’ question is really inspiring.

http://www.jonobacon.org/2010/08/23/getting-more-developers-interested-in-participating-in-ubuntu/

http://fnords.wordpress.com/2010/08/24/getting-more-developers-interested-in-ubuntu/

Los links dicen mucho, al parecer en la version 11.04 la comunidad tratara de involucrar a mas personas en el desarrollo de ubuntu, ojala sea asi =)

The links are very descriptive, it seems like in the 11.04 version developers will try to push harder to new comunity members to join the differents teams to improve ubuntu even more!, I really hope they can do it =)

https://lists.ubuntu.com/archives/ubuntu-beginners/2010-October/001196.html

El resumen del UDS (ubuntu developer submit), los UDS son reuniones que se hacen antes de comenzar a trabajar en una nueva version donde se decide en que trabajaran los desarrolladores en el ciclo actual.

The UDS (ubuntu developer submit) summary, the UDS is a meeting which is done before the developers start working in the next release, many important decisions are defined here.

https://lists.ubuntu.com/archives/ubuntu-beginners/2010-October/001196.html

Un hilo de #ubuntu-beginners con varios blogs como este.

A #ubuntu-beginners thread with several blogs like this.

http://daniel.holba.ch/blog/?p=806

Han liberado la nueva version de Harvest ( http://harvest.ubuntu.com/ ), al parecer una plataforma para hacer mas facil la colaboracion con ubuntu, probe la version beta, pero no lo entendi, sin embargo creo que habra tutoriales para aprender a usarlo, lo seguire de cerca

The new version of Harvest (http://harvest.ubuntu.com/) has been released, it seems like  a platform to making easier to collaborate with ubuntu, I tested the beta version but to be honest I didn’t get it, however it seems like tutorials will be made to get involved with it, I’ll look forward to it.

Eso es todo, aaa, tambien han aceptado 2 de mis parches ^_^, pufff, tambien tengo que volver a ponerme en contacto con mradn (https://launchpad.com/~mrand), a estas alturas supongo que creera que estoy muerto X_X

That’s all I’ve read lately, ohhh, also 2 of “my” patches has been accepted ^_^, pufff, I need to get in touch with mrand again (https://launchpad.com/~mrand), he must think I’m dead X_X