Canonical Voices

Posts tagged with 'motu'

Daniel Holbach

As part of our Fix-It Fridays we saw many many new faces joining the #ubuntu-motu IRC channel which always has many helpful developers who are there to answer questions and help if you should get stuck. Still it seems like some feel uncomfortable asking questions or getting their feet wet in this forum.

After some discussion we thought it might make sense to have an additional low-key event where you can show up, get to know everyone and ask whatever you have on your mind. With Google+ Hangouts becoming more and more popular, we will offer a couple of hangouts tomorrow where you can get easily involved and in touch with us.

Daniel hanging out

Building up to this week’s Fix-It Friday, we will be there for you tomorrow, 8th March 2012 at:

in the ‘ubuntu-dev’ hangout.

We are looking forward to seeing you there to give you a warm welcome to our Ubuntu development community. To get an idea of how things work, you might want to check out the first few articles of our Ubuntu Development Guide.

Read more
Daniel Holbach

Welcoming Monday is a lot easier if you have a great weekend to look back to. 32 LoCo teams in 23 countries definitely had a great time at Ubuntu Global Jam.

The Fix-It Friday activity continued for hours and I thought it’d be a nice idea to go through just a few bits that came in and showcase what exactly was done, so it becomes a bit clearer what all constitutes as a “fix” for Ubuntu 12.04.

Before we dive into discussing fixes, I’d like to thank everyone who contributed to the event. The atmosphere was great and super-productive. I hope to see you all next Friday again! :-)

  • Barneedhar had a look at the list of release-critical bugs which were fixed in Debian that haven’t made it to Ubuntu yet. On the list was a motion upload (3.2.12-3.1) which (among other things) fixed Debian bugs 640562 (build failure with libav/0.7.1). This was fixed in Ubuntu as well before, but differently. What Barneedhar did was: review the differences between Debian and Ubuntu and make sure nothing of importance was dropped, then kick off a test-build of the Debian version in current Ubuntu, see if everything still works. The test results were positive, so we could sync the package from Debian and eliminate the delta between Debian and Ubuntu. Excellent work!
  • Leo Iannacone had a look at a bug report about librsvg failing to build. When looking at a bug report, it’s a good idea to first check if you can reproduce it. Leo checked and found that it  still builds on i386 and amd64. Great – the bug could be closed! (Just a tip while we’re at it: If you have an amd64 machine, you can easily build i386 packages, by running ‘pbuilder-dist precise i386 build …’ instead of the regular ‘pbuilder-dist precise build …’.)

A lot of other bug fixes were contributed, patches were reviewed and upload, questions answered, and lots more. Some bug fixes are still being reviewed, some weren’t mtnentioned on the etherpad we used during Fix-It Friday, but lots and lots of new contributors showed up in the last few days (expect an update as part of the weekly “Ubuntu 12.04 Development update”).

Thanks a lot everyone for your great work. You all make Ubuntu as great as it is! :-)

Read more
Daniel Holbach

This is going to be a real Ubuntu weekend. Not only is Ubuntu Global Jam kicking off today, but there is also Fix-It Friday going on and the Linaro/ARM teams are having an ARM Porting Jam.

If you always felt like getting more involved in Ubuntu, this weekend might be just the right opportunity.

The Ubuntu Global Jam page lists a number of events in all parts of the world, on the list of countries there are: Egypt, Tunisia, Bangladesh, Hong Kong, India, Malaysia, Myanmar, Australia, Czech Republic, Greece, Ireland, Italy, Slovenia, Spain, Canada, Mexico, USA, Brazil and Trinidad and Tobago. If you can’t find an event near you, check out the general Jam page to find a number of things you can get involved with in any case.

If you know the ARM architecture well and want to get involved, get in touch with the fine people organising the ARM Porting Jam.

If you were always interested in Ubuntu development, I have very good news for you. Here’s the details:

Great times ahead everyone, let’s make Ubuntu better together!

Read more
Daniel Holbach

A lot of really great things are coming together right now: tomorrow we kick off Ubuntu Global Jam for the 12.04 cycle, additionally we will have Fix-It Friday tomorrow!

The Ubuntu developer community is putting a lot of effort into this event. There will be experienced developers who

  • take the time to answer all the questions you have,
  • help you fix problems,
  • review code for you,
  • use the time to clear up the sponsoring queue.

Here’s something you can do for us: get involved! Seriously, the more people show up, the more fun it will be, so if you are still hesitant, just show up: We are friendly, we’ll help out and we will have a great time.

If you want to prepare yourself a bit, check out these articles first: Introduction to Ubuntu development, Getting Set Up and Fixing a bug in Ubuntu. Please also give us feedback about them. If there’s anything unclear, wrong or confusing, we will fix it. We not only want a precise 12.04 release, but also precise Ubuntu development docs!

I’m looking forward to seeing you all tomorrow! :)

Read more
Daniel Holbach

Since I heard it, I always like the idiom “to hit the ground running”. There’s no really good German translation of it, but the thought of arriving somewhere, knowing what to do and how to do it definitely has its charm. In practical terms it’s often hard, especially if there’s complicated rules, tools and processes.

I won’t deny that there’s an interesting learning experience involved if you want to get into Ubuntu development. The experience will involve a couple of round-trips, as there is no one-size-fits-all solution to every single package or piece of software.

The good news is though[1]: it’s a lot easier than you think and we’re there to help you.

On Friday, 2nd March 2012, a lot of Ubuntu developers and contributors are going to be there to actively help you get started with Ubuntu Development. This is a great opportunity to ask all your questions, get to know a bunch of really friendly and helpful people and learn lots and lots about Ubuntu and Open Source development. It will almost be like hitting the ground running.

So you like the idea to help make Ubuntu better for millions of users on servers, desktops, laptops, TVs, phones and elsewhere?

There are two lists of items we want to look into fixing together:

  1. Packages which don’t build anymore.
    If you have worked with compiling source code before, you know that a mistake like a syntax error can get you into a situation where the build is broken and does not succeed. There are lots of other reasons why this might happen, a good idea is usually to review the build log referenced in the link above.
  2. Bugs which have been fixed elsewhere.
    Our bug life cycle works like this: make sure the bug can be reproduced reliably, gather all the information necessary, figure out if it’s an Ubuntu-specific problem or if it happens in the vanilla code of the software authors as well, then forward the bug with all the relevant information upstream. The Launchpad bug tracker is a great tool, which puts us into the situation where we are able to go through bugs which were fixed elsewhere already. Taking these fixes and applying them to Ubuntu is a great target for improvements, especially being eight weeks away from release.

There’s only two things you need to do:

  1. Make yourself familiar with Ubuntu development. Just these three articles will give you a good start: Introduction to Ubuntu development, Getting Set Up and Fixing a bug in Ubuntu. (Feel free to read more if you like. ;-) )
  2. Join us in #ubuntu-motu on irc.freenode.net on Friday, 2nd March 2012 and we will answer all your questions, hang out with you, review code for you and have a good time.

The great thing is: this also coincides with Ubuntu Global Jam, so expect people from all around the globe to hang out and make Ubuntu better.

[1] … and this is where the actual blog post starts. :-)

Read more
Daniel Holbach

WOW. So this was our first Fix-It Friday and there’s still a few to come until release. Here’s what we collectively got through:

What the people above can do, you can do easily! Just make sure you’re there next time. I’m super super happy about Fix-It Friday turned out the first time and as I said above: there will be more… and this one isn’t even over yet! :-)

Thanks everyone and ROCK ON!

Read more
Daniel Holbach

Every Friday
Every Friday…
we hack with you

...we hack together with you...

on Ubuntu

...on Ubuntu.

It's no Rocket Science

It's no Rocket Science...

but rather a lot of fun

...but rather a lot of fun!

Join us

Join us and...

...you'll make lots of friends!

...you'll make lots of friends!

Here’s what you need to do:

  1. Read the first few articles.
  2. Join us in #ubuntu-motu on irc.freenode.net on Friday.
  3. Have fun and start making Ubuntu better!

More info here.

Read more
Daniel Holbach

I have been writing weekly Ubuntu development updates for about one cycle now. As many seem to like these updates, it’s time to raise the bar a bit. As I can’t do this just on my own, I need your help.

After some discussion with the Ubuntu News team, we agreed that development news can now be submitted to the ubuntu-news-team mailing list by simply sending a mail there with “[dev]” in the subject. To get a better idea of which kind of news we are looking for, check out the development news wiki page.

This is a very important service, as it will help us all to stay informed in our huge development community, it will make our efforts more transparent and inspire others to help out or get involved in similar efforts, so if you have just a few news bits, send them there. If you want to thank somebody for their work, tell us about it.

Also if you have ideas for additional topics we should write about, either send a mail or add a comment below.

Also am I looking for contributors, who would like to get involved in writing and collecting information about Ubuntu development. It’s not a huge amount of work, but should be pretty fun. If you are interested, please leave a comment below or drop me an email.

Read more
Daniel Holbach

Some weeks ago, I asked for feedback in a survey about Ubuntu development. Particularly, how well we reach out and how Ubuntu development is generally perceived were focus points of the survey. The great thing is: we had ~350 people replying and we have lots of great feedback and ideas in the results.

You can download the summary (including all the answers) here.

Let’s use all the feedback to make Ubuntu development even easier.

Thanks everyone for your replies!

Read more
Daniel Holbach

I love planning a new Ubuntu release. It’s a great experience to take a few steps back and look at the biggest challenges and opportunities in your area of interest and try to identify the most promising.

Personally, I want us to get better at involving interested Ubuntu users in the development process. We have gotten better and better over the years, but there’s still things we can do better. The fantastic answers in the survey I announced recently helped a lot to see the issues more clearly. (Expect a report of the survey soon.)

So here’s the list of blueprints I registered and where I expect some movement next cycle (feel free to subscribe to any of these, and follow along, if you’re not at UDS):

  • Celebrating developer contributions
    How can we get better at celebrating contributions to Ubuntu development? There is massive amounts of great work going into Ubuntu, some of this is under the radar because it is less visible. Celebrating this more publicly would be both inspiring for those who did the good work, and others who didn’t know about the great work before.
  • Developer Advisory Team
    As opposed to having fully-fledged 1-on-1 mentoring, we might want to think of a much more light-weight approach and coordinate efforts such as: 1) reach out to new contributors, thank them for their work and get feedback, 2) reach out to people who might be ready to apply for upload rights and help them, 3) reach out to contributors that went inactive and get feedback from them and offer help.This should be easily manageable by a small team and would make the developer world a much more social experience.
  • Development documentation improvements
    It’d be worth to discuss the list of open issues of our developer documentation and review the results of the recent survey.
  • Making Harvest rock
    Harvest hasn’t seen much development recently, but we still need a good place to summarise all the needed work in the distribution.Problems both in representation and data should be discussed.
  • Reaching out to future Ubuntu developers
    There is a huge interest in getting involved in Ubuntu development. We want to better reach out to everybody who is interested. The recent survey data will probably help with the discussion of this.
  • Weekly Ubuntu Development News
    We have weekly development updates already, so these can serve as a good piece of news infrastructure. We need to put the project on broader feet and figure out submissions processes, etc. Also are we going to talk about new interesting news bits we might want to include.

These are just the sessions that I will be leading, there will be loads more I’ll attend and contribute to though. :-)

I’m looking forward to this great UDS!

Read more
Daniel Holbach

The Ubuntu Packaging Guide has made a lot of progress since its inception and we have a bunch of great articles together already, which make it a lot easier for newcomers to get a sense of direction and find out how to use the tools.

Some of us have been filing bug reports about it recently, and it’d be great to get them fixed and out there. If you are new to the packaging world, but still want to help out, just say so in your merge proposal and we give it another fact check.

The good news is, the process of fixing these bugs is quite simple, just:

  • bzr branch lp:ubuntu-packaging-guide
  • <edit and fix>
  • bzr commit
  • bzr push lp:~<yourlaunchpadid>/ubuntu-packaging-guide/<bugnumber>
  • bzr lp-open
  • <click on “(+) Propose for merging”>

Here is a list of bugs that would be great to have fixed:

And here is a list of articles that still need to be written:

Be bold, propose changes – every little fix will help.

(Here’s a list of more bugs.)

If you haven’t checked out the Packaging Guide yet, here is it online, or install it like this:

  1. sudo add-apt-repository ppa:ubuntu-packaging-guide-team/ppa
  2. sudo apt-get update
  3. sudo apt-get install ubuntu-packaging-guide

Read more
Daniel Holbach

You were always interested in Ubuntu Development and gave it a try already? Perfect!

With Ubuntu 11.10 almost out the door, we started the planning of the 12.04 (precise) development cycle and we would love to know how well our documentation is known and working today, so we can see what we can improve.

SurveyPlease give us your feedback in this short survey – it just takes a few minutes (if you’re not trying to write a novel in reply). Have your say and help us improve!

Thanks a bunch in advance! :)

Read more
Daniel Holbach

I have written about our sponsorship process loads of times already. When new contributors have no upload rights to Ubuntu yet, this process ensures that we get the code reviewed and included in Ubuntu. In the cases you branch a source package, make changes, push to Launchpad and propose a merge. The other alternative is to add a patch to a bug report and subscribe the sponsors team.

Over the last few releases we improved documentation, tools and processes and got more people involved.

I’d like to have your comment as a contributor or as a reviewer: how well does it work for you? What are you remaining gripes? What do you love about it?

Read more
Daniel Holbach

Your chance to get involved!

Barry just spilled the beans about it: we are going to have a dh_python2 porting jam on 23rd June. Here’s what he says:


This Thursday, June 23rd, we are going to have a dh_python2 porting jam. If you know about packaging, and have meddled with Python packaging before, we invite you to hang out and port a load of packages with us.

We have some documentation to explain better what exactly we’re going to be doing, and why:

https://wiki.ubuntu.com/BarryWarsaw/PythonHelpers

You are of course welcome to start working on these, fixing them and getting them included in Ubuntu, but if you wait for the 23rd, we will offer this for you:

  • IRC Training sessions in #ubuntu-pyjam at 1300 and 1800 UTC
  • Lots of fun and good atmosphere
  • Reviewers who can check and upload your code for you. (In addition to

our regular patch pilots we will have additional people to make
sure all merge requests are tended to.)

If this sounds great to you, make sure pencil in this Thursday, June 23rd into your calendar and just show up in #ubuntu-pyjam on irc.freenode.net.


Just to make it clear: you will need a bit of packaging experience to get involved, but hanging out in the channel and working your way through these guides (Intro, Get Set Up, Fix bugs) should be a very good start.

Thanks a lot Barry for organising this – this will be awesome! :-)

Read more
Daniel Holbach

Weekly Ubuntu Development Update

Ubuntu Development Update

Development of Oneiric (Ubuntu 11.10) is in full swing, we just got Alpha 1 out last week and here’s the list of dates that are coming up in the next few weeks:

  • June 30th, Debian Import Freeze which means that packages will not be synced automatically any more, but have to be requested manually.
  • July 7th, release of Alpha 2.
  • July 11th to 15th, Ubuntu Developer Week! A week full of development tutorials, workshops and interactive sessions.
  • August 4th, release of Alpha 3.
  • August 11th, Feature Freeze until which features have to have mostly landed in Ubuntu. They will of course still have bugs that have to get ironed out, but most of the hard work will be there already.

As you can see times are exciting right now. There is a lot of hard work going on, lots is still broken in Oneiric, but it’s a great time to get your feet wet, try out things and fix a few bugs on the way.

I’m very happy to see that Full Circle Magazine is now having a new series about Ubuntu Development. Issue 49 has the first installment of this. Be sure to check it out!

New Contributor

This week I talked to Paolo Sammicheli, who is an Ubuntu Member from the Italian Community. He was involved in several things like translations, marketing, advocacy and testing. He also is an UDS addict and since UDS Jaunty spent his holidays attending it. He says “This cycle I decided to move my interests into development and I’m slowly learning packaging. Spare time is never enough :)

I asked Paolo what his personal experience of the development was like and he had this to say:

  • Yes, I tried some merges and few sync. The experience was good, also because I’ve found in the Italian Dev Team people willing to mentoring me and being already an Ubuntu Member helped me to find easily who-ask-what.
  • Paolo was struggling a bit to find tasks to work on. Some of the bitesize bugs he tried were solved already, but when he tried a few merges that worked out better for him, because “comparing the previous ubuntu version with the debian version you start understanding how patches works, how tools works and so on.
  • When merging Paolo found it helpful to get in touch with the person who uploaded it last. A bunch of people were happy to review his merge and upload it. In some cases he didn’t get a reply, which was a bit frustrating. Looks like this is something we can all improve!

Get Involved

  1. Read the Introduction to Ubuntu Development. It’s a short article which will help you understand how Ubuntu is put together, how the infrastructure is used and how we interact with other projects.
  2. Follow the instructions in the Getting Set Up article. A few simple commands, a registration at Launchpad and you should have all the tools you need, and you’re ready to go.
  3. Check out our instructions for how to fix a bug in Ubuntu, they come with small examples that make it easier to visualise what exactly you need to do.

Find something to work on

Pick a bitesize bug. These are the bugs we think should be easy to fix. Here’s a few examples:

In addition to that there are loads more opportunities over at Harvest.

Talk to us in #ubuntu-motu on irc.freenode.net to get all your questions answered.

Read more
Daniel Holbach

Development Documentation

I’m happy to say that the Packaging Guide project has seen a lot of activity recently, so a bunch of articles have been improved and new articles been added. Thanks a lot to Andrew, Barry and others.

You can download it or read it on its preliminary home. (Expect an announcement of its new and lasting place soon.)

I got a number of questions about the guide in the last few days and I think it’d make sense to clarify the intention behind the guide. We never intended to rewrite or replace other fantastic documentation about packaging that exists already (think Debian New Maintainers’ Guide, Debian Policy Manual, etc.), but we want to have a place where new contributors to Ubuntu get a good and well-rounded introduction to Ubuntu, plus a more maintainable place for “knowledge-base type” articles that are currently spread across the wiki and other places in varying forms of style or out-of-date-ness.

For the project we need feedback and help. If you are interested in helping out, please check out the list of open requests, read the current guide and file bugs.

I’m very excited about this project and feel the quality of it is getting better and better.

Read more
Daniel Holbach

Getting people involved

As part of my job I have often thought about what motivates somebody to get involved with Ubuntu development or more generally with Open Source development in general. There’s a couple of conclusions I came through, both through my own experience and observations and discussions with others. Here’s my Top 3:

  1. The project needs to be exciting. The atmosphere needs to be welcoming and friendly.
  2. The documentation needs to be clear.
  3. Contributors need to find their first tasks easily.

Regarding 1) I think we’re doing a great job. It’s a lot of fun to be part of the Ubuntu development team and I think almost everybody can easily say that they made lots of friends there. Working on Ubuntu is exciting, because you fix problems not only for you, but also for millions of users.

We’re actively working on 2). The newly revamped Packaging Guide is still work in progress, but expect an announcement soon.

One area of focus for this cycle should be 3). We often face new contributors who say “Yeah, I read all the documentation – what do I do now?” There’s all kinds of tasks we can set for new contributors. We can try to just point them to Harvest, we can involve them in some organised activities, and lots of other things.

In the UDS session “Initiatives to involve new developers” we discussed a very light-weight approach: if you encounter a bug that should be easy to solve, but probably not what you want to work on yourself right now, just

  • tag it as ‘bitesize’,
  • subscribe yourself,
  • add a comment saying that it should be a bug that’s simple to fix and
  • offer your help.

It’s not a huge commitment to help somebody fix one bug, so let’s all try to tag a few more to make sure we give new contributors something to sink their teeth in.

Luckily: there’s a script in oneiric’s ubuntu-dev-tools, that does just that: it’s called “bitesize”. :-)

Read more
Daniel Holbach

I just set up a daily build for the Ubuntu Packaging Guide. To get the latest goodness, simply:

  1. sudo add-apt-repository ppa:ubuntu-packaging-guide-team/ppa
  2. sudo apt-get update
  3. sudo apt-get install ubuntu-packaging-guide
  4. <point your browser to /usr/share/doc/ubuntu-packaging-guide>

Once installed, you get a handy packaging guide in PDF, HTML, Single HTML and ePub formats.

If you have any feedback from the guides, please file bug reports. Also can we need some help massaging the old packaging guide into reStructuredText. Have a look at the open bug reports to see what we’re currently working on and looking for.

Read more
Daniel Holbach

This is another article of the new Ubuntu Packaging Guide project. Please leave your comments below, or report a bug on it, or start helping out. Just branch the code and get involved.

The article below is all about fixing bugs in Ubuntu.


Fixing a bug in Ubuntu

Introduction

If you followed the instructions to get set up with Ubuntu Development, you should be all set and ready to go.

As you can see in the image above, there is no surprises in the process of fixing bugs in Ubuntu: you found a problem, you get the code, work on the fix, test it, push your changes to Launchpad and ask for it to be reviewed and merged. In this guide we will go through all the necessary steps one by one.

Finding the problem

There is a lot of different ways to find things to work on. It might be a bug report you are encountering yourself (which gives you a good opportunity to test the fix), or a problem you noted elsewhere, maybe in a bug report.

Harvest is where we keep track of various TODO lists regarding Ubuntu development. It lists bugs that were fixed upstream or in Debian already, lists small bugs (we call them ‘bitesize’), and so on. Check it out and find your first bug to work on.

Figuring out what to fix

If you don’t know the source package containing the code that has the problem, but you do know the path to the affected program on your system, you can discover the source package that you’ll need to work on.

Let’s say you’ve found a bug in Tomboy, a note taking desktop application. The Tomboy application can be started by running /usr/bin/tomboy on the command line. To find the binary package containing this application, use this command:

$ apt-file find /usr/bin/tomboy

This would print out:

tomboy: /usr/bin/tomboy

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

$ apt-cache show tomboy | grep ^Source:

In this case, nothing is printed, meaning that tomboy is also the name of the binary package. An example where the source and binary package names differ is python-vigra. While that is the binary package name, the source package is actually libvigraimpex and can be found with this command (and its output):

$ apt-cache show python-vigra | grep ^Source:
Source: libvigraimpex

Getting the code

Once you know the source package to work on, you will want to get a copy of the code on your system, so that you can debug it. This is done by branching the source package branch corresponding to the source package. Launchpad maintains source package branches for all the packages in 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 or your excellent fix – and you get a little bit of credit. You’re now on your way to becoming an Ubuntu developer!

We’ll describe specifics on how to branch the code, push your fix, and request a review in the following sections.

Work on a fix

There are entire books written about finding bugs, fixing them, testing them, etc. If you are completely new to programming, try to fix easy bugs such as obvious typos first. Try to keep changes as minimal as possible and document your change and assumptions clearly.

Before working on a fix yourself, make sure to investigate if nobody else has fixed it already or is currently working on a fix. Good sources to check are:

  • Upstream (and Debian) bug tracker (open and closed bugs),
  • Upstream revision history (or newer release) might have fixed the problem,
  • bugs or package uploads of Debian or other distributions.

If you find a patch to fix the problem, say, attached to a bug report, running this command in the source directory should apply the patch:

$ patch -p1 < ../bugfix.patch

Refer to the patch(1) manpage for options and arguments such as --dry-run, -p<num>, etc.

Testing the fix

To build a test package with your changes, run these commands:

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

This will create a source package from the branch contents (-us -uc will just omit the step to sign the source package) and pbuilder-dist will build the package from source for whatever release you choose.

Once the build succeeded, install the package from ~/pbuilder/<release>_result/ (using sudo dpkg -i <package>_<version>.deb). Then test to see if the bug is fixed.

Documenting the fix

It is very important to document your change sufficiently so developers who look at the code in the future won’t have to guess what your reasoning was and what your assumptions were. Every Debian and Ubuntu package source includes debian/changelog, where changes of each uploaded package are tracked.

The easiest way to do this is to run:

$ dch -i

This will add a boilerplate changelog entry for you and launch an editor where you can fill out the blanks. An example of this could be:

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

With that out of the way, let’s focus on the actual changelog entry itself: it is very important to document:

  1. where the change was done
  2. what was changed
  3. where the discussion of the change happened

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.

Committing the fix

With the changelog entry written and saved, you can just run:

debcommit

and the change will be committed (locally) with your changelog entry as a commit message.

To push it to Launchpad, as the remote branch name, you need to stick to the following nomenclature:

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

This could for example be:

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

So if you just run:

bzr push lp:~emmaadams/ubuntu/natty/specialpackage/fix-for-123456
bzr lp-open

you should be all set. The push command should push it to Launchpad and the second command will open the Launchpad page of the remote branch in your browser. There find the “(+) Propose for merging” link, click it to get the change reviewed by somebody and included in Ubuntu.

Read more
Daniel Holbach

This is the second article showcasing what we have in the new packaging guide already. The article this time is about getting your development environment set up.


Getting Set Up

There are a number of things you need to do in the beginning to enable you to do Ubuntu development. A few of them you have to do locally on your system. In addition to that you also need to inform Launchpad about yourself, so it accepts changes you want to make.

When you followed all the steps in this article,

  • you have all the tools to do Ubuntu development installed on your machine,
  • your local developer tools know about you, which simplifies work a lot,
  • you can do local builds of packages,
  • you can interact with other developers and propose your changes on Launchpad to get merged,
  • you can upload packages to Launchpad, so they are hosted in your Personal Package Archive (PPA).

Run the development version

It is advisable to run the current development version of Ubuntu. It will allow you to test changes in a “live environment” where they are actually built and tested in the development release you upload them to.

https://wiki.ubuntu.com/UsingDevelopmentReleases shows a variety of ways to use the development release in a safe way.

Install the tools locally

There are a number of tools that will make your life as an Ubuntu developer much easier. You’ll encounter these tools later in this guide. To install most of the tools you’ll need, run this command:

$ sudo apt-get install gnupg pbuilder \
  ubuntu-dev-tools bzr-builddeb apt-file

These packages include:

  • gnupgGNU Privacy Guard contains tools you will need to create a cryptographic key with which you will sign files you want to upload to Launchpad.
  • pbuilder – a tool to do a reproducible builds of a package in a clean and isolated environment.
  • ubuntu-dev-tools (and devscripts, a direct dependency) – a collection of tools that make many packaging tasks easier.
  • bzr-builddeb (and bzr, a dependency) – distributed version control tools that makes it easy for many developers to collaborate and work on the same code while keeping it trivial to merge each others work.
  • apt-file provides an easy way to find the binary package that contains a given file.
  • apt-cache provides even more information about packages on Ubuntu.

Setting up a GPG key

GPG stands for GNU Privacy Guard and it implements the OpenPGP standard which allows you to sign and encrypt messages and files. This is useful for a number of purposes. In our case it is important that you can sign files with your key, so they can be identified as something that you worked on. If you upload a source package to Launchpad, it will only accept the package if it can absolutely determine who uploaded the package.

To generate a new GPG key, run:

$ gpg --gen-key

GPG will first ask you which kind of key you want to generate. Choosing the default (RSA and DSA) is fine. Next it will ask you about the keysize. The default (currently 2048) is fine, but 4096 is more secure. Afterward, it will ask you if you want it to expire the key at some stage. It is safe to say “0”, which means the key will never expire. The last questions will be about your name and email address. Just pick the ones you are going to use for Ubuntu development here, you can add additional email addresses later on. Adding a comment is not necessary. Then you will have to set a passphrase. Choose a safe one. Now GPG will create a key for you, which can take a little bit of time; it needs random bytes, so if you give the system some work to do it will be just fine. Move the cursor around!

Once this is done, you will get a message similar to this one:

pub   4096R/43CDE61D 2010-12-06
      Key fingerprint = 5C28 0144 FB08 91C0 2CF3  37AC 6F0B F90F 43CD E61D
uid                  Daniel Holbach <dh@mailempfang.de>
sub   4096R/51FBE68C 2010-12-06

In this case 43CDE61D is the key ID.

To upload (the public part of) of your key to a keyserver, so the world can identify messages and files as yours, just run:

$ gpg --send-keys <KEY ID>

There is a network of keyservers that will automatically sync the key between themselves.

Setting up an SSH key

SSH is a network protocol that allows you to exchange data in a secure way over the network. In a lot of cases you will use it to access and open a shell on another machine. It is also very useful to transfer files in a secure way.

To generate a SSH key, run:

$ ssh-keygen -t rsa

The default file name usually makes sense, so you can just leave it as it is. For security purposes, it’s highly recommended that you use a passphrase.

We will use the SSH key to securely push code changes to Launchpad.

Setting up pbuilder

pbuilder allows you to build packages locally on your machine. It serves a couple of purposes:

  • the build will be done in a minimal and clean environment, where you can see if it succeeds in a reproducible way (with no modifications of the local system
  • there is no need to install all necessary build dependencies locally
  • you can set up multiple instances for various Ubuntu and Debian releases

Setting pbuilder up is very easy. Edit ~/.pbuilderrc and add the following line to it:

COMPONENTS="main universe multiverse restricted"

This will ensure that build dependencies are satisfied using all components.

Then run:

$ pbuilder-dist <release> create

where <release> is for example natty, maverick, lucid or in the case of Debian maybe sid. This will take a while as it will download all the necessary packages for a “minimal installation”. These will be cached though.

Set up your development environment

There are a few things you’ll need to set up in your development environment before you can start working on packages.

Launchpad

Launchpad is the central piece of infrastructure we use in Ubuntu. It stores not only our packages and our code, but also things like translations, bug reports, information about the people who work on Ubuntu and which teams they are part of. You’ll also use Launchpad to publish your proposed fixes, and get other Ubuntu developers to review and sponsor them.

You will need to register with Launchpad and provide a minimal amount of information, so that you can download and upload code, submit bug reports, and more.

Setting up an account

If you don’t already have a Launchpad account, you can easily create one. If you have a Launchpad account but cannot remember your Launchpad id, you can find this out by going to https://launchpad.net/people/+me and looking for the part after the ~ in the URL.

Launchpad’s registration process will ask you to choose a display name. It’s encouraged for you to use your real name here. so that your Ubuntu developer colleagues will be able to get to know you better.

When you register a new account, Launchpad will send you an email with a link you need to open in your browser, in order to verify your email address. If you don’t receive it, check in your spam folder.

https://help.launchpad.net/YourAccount/NewAccount has more information about the process and additional settings you can change.

Uploading the GPG key to Launchpad

To find about your GPG fingerprint, run:

$ gpg --fingerprint <email@address.com>

and it will print out something like:

pub   4096R/43CDE61D 2010-12-06
      Key fingerprint = 5C28 0144 FB08 91C0 2CF3  37AC 6F0B F90F 43CD E61D
uid                  Daniel Holbach <dh@mailempfang.de>
sub   4096R/51FBE68C 2010-12-06

Head to https://launchpad.net/people/+me/+editpgpkeys and copy the part about your “Key fingerprint” into the text box. In the case above this would be 5C28 0144 FB08 91C0 2CF3  37AC 6F0B F90F 43CD E61D. Now click on “Import Key”.

Launchpad will use the fingerprint to check the Ubuntu key server for your key and, if successful, send you an encrypted email asking you to confirm the key import. Check your email account and read the email that Launchpad sent you. If your email client supports OpenPGP encryption, it will prompt you for the password you chose for the key when GPG generated it. Enter the password, then click the link to confirm that the key is yours.

Launchpad encrypts the email, using your public key, so that it can be sure that the key is yours. If your email software does not support OpenPGP encryption, copy the encrypted email’s contents, type gpg in your terminal, then paste the email contents into your terminal window.

Back on the Launchpad website, use the Confirm button and Launchpad will complete the import of your OpenPGP key.

Find more information at https://help.launchpad.net/YourAccount/ImportingYourPGPKey

Uploading your SSH key

Open https://launchpad.net/people/+me/+editsshkeys in a web browser, also open ~/.ssh/id_rsa.pub in a text editor. It is the public part of your SSH key, so it is safe to share it with Launchpad. Copy the contents of the file and paste them into the text box on the web page that says “Add an SSH key”. Now click “Import Public Key”.

More information is available at https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair

Teaching Bazaar about you

Bazaar is the tool we use to store code changes in a logical way, to exchange proposed changes and merge them, even if development is done concurrently.

To tell Bazaar who you are, simply run:

$ bzr whoami "Bob Dobbs <subgenius@example.com>"
$ bzr launchpad-login subgenius

whoami will tell Bazaar which name and email address it should use for your commit messages. With launchpad-login you set your Launchpad ID. This way code that you publish in Launchpad will be associated with you.

Note: If you can not remember the ID, go to https://launchpad.net/people/+me and see where it redirects you. The part after the “~” in the URL is your Launchpad ID.)

Introducing you to the development tools

Similar to Bazaar, the Debian/Ubuntu packaging tools need to learn about you as well. Simply open your ~/.bashrc in a text editor and add something like this to the bottom of it:

$ export DEBFULLNAME="Bob Dobbs"
$ export DEBEMAIL="subgenius@example.com"

Now save the file and either restart your terminal or run:

$ source ~/.bashrc

(If you use a different than the default shell, which is bash, please edit the configuration file for that shell accordingly.)

Read more