Canonical Voices

Posts tagged with 'motu'

Matt Fischer

Being a MOTU

Back in October, I wrote a post about my process of becoming a MOTU. I’ve been pretty busy since October. First of all, I had this 9 month build finally finish:

Successfully signed dsc and changes files

Successfully signed dsc and changes files

Once things sort of settled down from that, I jumped back in to updating and syncing packages. This time I was mainly focusing on desktop packages, because that’s the group my mentor worked on. However, I wanted to get some different experiences, so I also worked on some new debian packages (one of which landed).

So after all this, I talked to a few people and it was suggested that I apply for MOTU. So I cleaned up my wikipage and applied for it. The DMB had a lot of questions in the meeting, but I guess I was persuasive enough because I was approved on June 6!

So what’s next? Personally, I want to keep doing updates, complete a SRU, land my other debian package, sponsor some packages, and help other people achieve their goal of being a MOTU also.

I feel that mentoring is probably one of the most important parts of being a MOTU, so even though I’m new, I’d love to help where I can. I can help by answering questions or helping with ideas of things to work on. Finding the work can sometimes be the hardest part, and the only path forward to becoming a MOTU is doing updates and syncs, so it’s critical to keep up the momentum. So if you’re working on this goal, find me on #ubuntu-motu as mfisch and we can chat.

Read more
Matt Fischer

EDIT: As several people have pointed out, there is a script to already to this, pull-lp-source. Perfect! I’ve asked numerous people over the last year about whether there was a tool that could do this and nobody mentioned this one (even asked on AskUbuntu last week). So out of all this I end up with a link to a great new tool and got to write some python yesterday. pull-lp-source looks like it will meet all my needs.

During my work on bug triage and trying to become MOTU, I’ve found myself wanting to be able to pull source packages for a specified release, for example, download source for lxc on precise, even if I’m using raring. Although you can do this if you setup apt with all the releases and then use pinning, or doing a setup like this, I wanted an easier way. So I decided to glue together rmadison and dpkg-source and create a tool called “get_source”. This is how it works.

get_source.py -r <release> -p <package>

Pulling the source for bc on oneiric:

get_source.py -r oneiric -p bc

Grabbing lxc on precise:

get_source.py -r precise -p lxc

Seems pretty simple and it is!

The tool relies on outside helpers to do the hard work, namely rmadison and dpkg-source, so you’ll need those installed to use it. Please give it a try and send in feedback and fixes. If you’re a developer you’ll note that I even have unit-ish tests, please add more if you make some fixes for corner-cases.

bzr branch lp:~mfisch/+junk/get_source

How It Works

  1. Run rmadison and build a list of packages + versions per release
  2. Find the release we care about. We now know the package name, version, and release name.
  3. Using some hueristics, download the dsc file.
  4. Read and parse the dsc file to find the filenames for the orig file and diff and/or debdiff
  5. Download the orig and diff/debdiff files
  6. Use dpkg-source -x to extract it

Alternatives and Issues

When I started this, I figured it would be simple, but I was mistaken. There is lots of variation on filenames and locations in the archives, for example:

  1. I had originally planned to just go grab http://url/pool/main/<package first letter>/package/package_version.<extension>, but it’s not quite that simple. First, not all packages use standard names, some have a diff.gz, some a debian.tar.gz. Then some packages use xz and some use gz.  Native packages won’t have a diff at all (I think), and right now I know my code won’t support that.
  2. There’s also the question of package directory. alsa-base for example comes from the directory “alsa-driver”. I plan on grabbing this information from apt-cache show, but even that will not solve the issue if I’m on raring and the package was elsewhere in precise. This is also not yet supported in this version.
  3. Packages like angband have a version of 1:3.0.9-1, and the “1:” portion is not included in the filename. The code now supports this.

I found these cases by making this app work for a package and then randomly trying more and more packages to find and hopefully fix new cases. The worry I have is that there are hundreds more corner-cases that I don’t handle. Given all these issues, I’m still releasing this code for other people to test, but perhaps someone has simpler solutions to the problems above? Even better, maybe someone has already written a better tool, which I’ll gladly use!

Read more
Matt Fischer

Becoming a MOTU

Ubuntu relies on “Masters of the Universe” or MOTUs to keep the universe and multiverse components of Ubuntu in good working order. Unlike main, which is officially supported by Canonical, universe and multiverse are community supported. So MOTUs are community members who spend their time adding, maintaining, and supporting these repos.

Even though I work for Canonical, I don’t have any special powers. If I want to upload a package to universe or multiverse, I need to talk to a MOTU or become one. In order to become one, I need to do the work and gain the experience required, just like anyone else in the community would. Since I came into this job without having done much of this tyoe of work before, I’ve started the process of becoming a MOTU by working with a mentor, Robert Ancell. Robert has helped me with the process, pointed out mistakes, and suggested packages to work on and has been a big help along the way.

Note: You must also be a Debian developer to get the battle cat. Also, Robert Ancell does not have blond hair.

So why do I want to become a MOTU? Personally, my motivation has several aspects:

  • I want to give back to the community
  • I want to learn more about Ubuntu and about the processes being used
  • It will make my job easier to have upload rights, more community contacts, and more experience with MOTU processes

I started this process last week by doing some gnome 3.6.0 updates, these were fairly simple, but helped me learn the process and tools. Since then, I’ve done five gnome 3.6.0 updates and three other non-gnome updates (two of which will be waiting until post-quantal to be uploaded).

As I progress in this goal, I’ll make updates on my blog and given an overview of some of the tools and processes being used.

If you want to start along the MOTU track there is no better place to start than the MOTU wiki and no better time than when R opens for development in November. While you wait for R to open, I’d recommend you read up on the policies and procedures and maybe make a dry-run through a package that can be updated in R. If you need help #ubuntu-motu on freenode is the place to ask! If you’ve already started, ping me on IRC (mfisch) or leave a comment here, I’d love to have another MOTU candidate to discuss things with and would be happy to assist you as well.

Read more