Ubuntu Developer Week: Getting started with Ubuntu Development : Part I

Tuesday, Jul 13th, 2010

Link

The first session of Ubuntu Develop week on “Getting started with Ubuntu Development” just ended. It was taken up by Daniel Holbach. I know reading IRC logs is boring, so here is sum up everything in human readable format. In between you will find quotation, which are actually when Daniel replies to some question asked by a person.

The entire text is given out by Daniel Holbach which I have converted from first person to third person speech.

IRC Channel: #ubuntu-classroom for classes (Freenode) and #ubuntu-classroom-chat for all discussions and asking questions

The whole session is of two parts

Getting a couple of tools installed and the environment set-up
Actively having a look at a few bugs and fixing them

Bookmark MOTU Getting Started and Ubuntu Development: Using Development releases

It is necessary to get the latest development release. It needs not be installed as main system but can be on a Virtual Machine (example Virtualbox) so that we can have access to all the current development libraries, modules and stuff and you can test packages better

Now go and enabled “Source code” and “universe” in System → Software Sources → Ubuntu Software if you havn’t

Questions:

tillux: wouldn’t it make sense to do that now? because you need to download a lot of things/packages etc
dholbach: no, it’d take too much time. It’s fine - you can just copy the instructions later on

umutuygar: What programming language r u going to be using?
dholbach: we’ll see :-) I think for now I’ll stick to packaging basics where we fix a couple of bugs

BeardyGnome13: QUESTION: will this be GNOME-centric?
dholbach: no, not at all

Type this command in terminal

sudo apt-get install –no-install-recommends bzr-builddeb ubuntu-dev-tools fakeroot build-essential gnupg pbuilder debhelper

which will give you a bunch of tools that are going to be useful generally, not just in these examples

The explanation of the packages

bzr-builddeb pulls in bzr which we’ll use to get the source code for one or two examples
ubuntu-dev-tools pulls in devscripts which both are incredibly helpful at making repetitive packaging tasks easy
fakeroot is needed by debuild (in devscripts) to mimic root privileges when installing files into a package
build-essential pulls in lots of useful very basic build tools like gcc, make, etc
gnupg is used to sign files in our case (uploads in the future)
pbuilder is a build tool that builds source in a sane, clean and minimal environment it sets up itself
debhelper contains scripts that automate lots of the build process in a package

Creating a GPG key

Now let’s move on the get our gpg key which we use it to sign files for upload but more generally it is used to sign and encrypt mails, files or text generally.

We use it to indicate that WE were the last to touch a file and not somebody else that ensures that only people who we know about get to upload packages

To generate a key, please run

gpg –gen-key

sticking to the defaults is totally fine, for example don’t you need a comment. If you need more info on gpg keys, head to https://help.ubuntu.com/community/GnuPrivacyGuardHowto which talks about everything in more detail.

Enter your name, email address and just stick to the default values for now. It could be that gpg is still sitting there and waiting for more random data to generate your key - that’s expected and fine. Just open another terminal while we carry on, it’ll finish on its own.

If you have your own GPG key already, skip this step.

Setting up pbuilder

Please open an editor and edit the file ~/.pbuilderrc (create if you don’t have it yet). Please add the following content to the file

COMPONENTS=“main universe multiverse restricted”

and save it. Once you’re done, please run

sudo pbuilder create

More about pbuilder:

It builds packages in a clean and minimal environment
It keeps your system “clean” (so you don’t install millions of build dependencies on your own system)
It makes sure the package builds in a minimal, unmodified environment
Oo you ensure that the package does not just build because you made lots of changes on your system, but the build is reproducable
You can update package lists (later on) with: sudo pbuilder update
To build packages you run: sudo pbuilder build package_version.dsc

BeardyGnome13: will the transcript of the classroom be available later?
leak-BebeChooCho: Will there be full log available?
dholbach: Yes. It will be linked from https://wiki.ubuntu.com/UbuntuDeveloperWeek. For the impatient: http://irclogs.ubuntu.com

How pbuilder works:

It first gets the minimal packages for a base system
Stores them in a tarball
whenever you build a package it’ll untar the base tarball, then install whatever your current build requires, then build it, then tear it all down again

somethinginteres: To confirm, the install of pbuilder etc should be done -right now- on our main box?
dholbach: It helps as you can perform the examples on your own machine and have it set up later on too

While gpg and pbuilder are doing their work, lets try out other tools

If you use the bash shell which is default, please edit ~/.bashrc and at the end of it, please add something like

DEBFULLNAME=“Daniel Holbach”
DEBEMAIL=“daniel.holbach@ubuntu.com”

and save it. PLEASE USE YOUR OWN NAME, THANKS :-)

abhi_nav: I am doing everything in my main day to day usable machine. is it ok? I dont want anything to ruine my cute ubuntu. :)
dholbach: yes, it’ll be fine

once you’re done editing ~/.bashrc, please run source ~/. bashrc (it’s only needed once)

tpw_rules87: Should these match the values we put into GPG?
dholbach: yes

OK, with this out of the way, the packaging tools will know you by your name and you don’t need to enter it, for example if you do changelog entries, etc.

Questions:

augdawg: where is the .bashrc file located?
dholbach: ~/.bashrc , so /home/<your user name>/.bashrc

abhi_nav:do i need to write my that email which i was used to create gpgp key some months ago? now I have another email
dholbach: yes, it helps to have the same in there, but you can also add another user id to your gpg key later on. Refer to https://help.ubuntu.com/community/GnuPrivacyGuardHowto for that

malcolmci: is the preferred arch for dev'ing AMD64 or i386 ?
dholbach: every supported architecture of ubuntu will work fine

devildante: Will this session revolve around packaging bugs, or bugs in general?
dholbach: I picked a few packaging bugs, but maybe we’ll do something else later on, let’s see :)

augdawg: what does the ~ mean?
dholbach: my user name is “daniel” , so ~ for me will be expanded to /home/daniel

tillux: for those running on lucid: should pbuilder have been triggered with “–distribution maverick” ?
dholbach: for now that’s fine - if you set up a maverick chroot/virtual-machine/partition/machine later on, you can just repeat the steps. For this sessions it’s irrelevant.

BeardyGnome13: is my gpg key machine-specific?
dholbach: no, you can just copy it to another machine

somethinginteres: PBuilder is downloading for Lucid, should it be downloading for Mavrick or Lucid?
dholbach: see what I just said to tillux above

theneoindian: i hate to ask , but will pbuilder create eat up my b/w .. i’m on a limited b/w connection …
dholbach: you better stop it then and repeat later on on a different connection

By the time pbuilders and gpgs are done, we keep talking a bit about ubuntu development and how it all works, we’ll make some good use of pbuilder and your shiny new gpg key later on :)

First things first: ubuntu is very special in how it’s produced and how we all work as you know it comes out every 6 months. That means we have a tight release schedule and everything we do and work on is defined by that schedule. Check out https://wiki.ubuntu.com/MaverickReleaseSchedule for the current release schedule for maverick.

The quick version: green means: lots is allowed here, red means: almost nothing is allowed here :)

Long version:

Toolchain is uploaded for the new release (gcc, binutils, libc, etc.), so the most basic build tools are there
New changes that happened in the meantime are synced or merged (more on that later on)
Ubuntu developer summit (uds) happens where features are defined and talked about
Up until debian import freeze we import source changes from debian semi-automatically
Up until feature freeze we get new stuff in, work on features, try to make it all work
If a feature is not half-way there yet by feature freeze, it will likely get deferred to the next release
From feature freeze on you can see that lots of freezes are added throughout the weeks and you’ll need more and more freeze exceptions for big changes

The focus is clearly: testing, testing, testing and fixing, fixing, fixing.

The more obvious fixes are (a huge 20 million line patch is not obvious) the more obvious the better. The same goes for fixes that are introduced AFTER the release. We just want to fix stuff in …-updates if it’s REALLY URGENT stuff with really simple fixes. So as you can imagine, this means: introduce big changes early in the release cycle, so we can shake out problems over a longer time.

devildante: On the release schedule, I see a column named “Work Item Iteration”
dholbach: Ah, yes. If you check out http://people.canonical.com/~pitti/workitems/maverick/all-ubuntu-10.10.html you will see a graph and loads of text. This is a list of work items defined by specifications written at the ubuntu developer summit. Work items are specific pieces of work that somebody at UDS decided to work on during the cycle. It’s more a tool for the managers at Canonical to keep their people busy. I mean… make sure we’re on track ;-)

Questions:

marceau: (I’ve asked this during the Userday as well but am wondering as to your input) Do you feel that the fast release cycle of Ubuntu might be hindering it’s progress? It seems a lot of time is spent in freezing and testing rather than working out new features.
dholbach: Not at all - I think it’s a good thing - it forces us to stay focused and make sure that stuff gets done. If we don’t get a feature done this cycle, it’ll be next cycle. Also it’s important for everybody else who works with the project, as it’s very easily predictable.

Daniel on how to get your stuff in:

When I spoke about gpg you noticed that I said that only people who “we know” get to upload packages directly. This means that as a new contributor you will have to work with sponsors who basically review your work and upload it for you. Once you did that a couple of times and they recognise you and your good work, you can apply for ubuntu developer membership and you can ask the people you’ve worked with for comments on your application.
It’s really not very complicated, you basically set up a wiki page with your contributions, ask for comments and submit for an irc meeting of the developer membership board and you’re done. No need to learn a secret handshake, send me money or anything else. It’s contributions and good work that counts. It helps if you’re a team player :)

Questions:

augdawg: what does an ubuntu developer membership get you?
dholbach: https://wiki.ubuntu.com/UbuntuDevelopers will tell you :). The most obvious thing is that you can upload changes yourself

prayii: But will sending you money help the process? *wink*
dholbach: unfortunately I’m not on the Developer Membership Board

tech2077: so when your a member do you get the ability to fix bugs somewhat more independently, trying to word it right
dholbach: It’s a question of trust: once you demonstrated that you do good work, you can get upload rights. Same goes for Ubuntu membership. People get an @ubuntu.com email address when they can be recognised for their good work in Ubuntu

marceau: what is the expected knowledge level of people taking part in this week’s sessions?
dholbach: I guess it will differ from session to session: in this session it’s good enough to be curious and have played with a terminal before and have a knack for making things work again :)

somethinginteres: is it the case that being an Ubuntu dev means being a programming vet or are there plenty of opportunity for n00bs to learn and contribute something..?
dholbach: there are lots of opportunities to learn, which is why we’re doing this whole thing :)

umang: If I’d like to contribute to both Ubuntu and Debian, which should I use?
dholbach: you can contribute to Debian by using Ubuntu and collaborating with Debian developers. It totally depends on you what you use and what you work on.

Now assuming pbuilder setup is complete, try getting the source of hello package

apt-get source hello

and run

sudo pbuilder build hello_*.dsc

this will kick off the build

abhi_nav: what .dsc stands for?
dholbach: great question. What “apt-get source” downloads is: (in most cases) an .orig.tar.gz file, which contains the source code of the software in a tarball released by the software authors. In some cases a .diff.gz file with changes that were applied to make the package build in the Ubuntu/Debian way and a .dsc file with metadata like checksums and the like it’s really not that important right now.

Once the build is done, you can check out the contents of /var/cache/pbuilder/result as it will contain the built hello .deb file :)

Now dealing with GPG. If you run

gpg –fingerprint your.name@email.com

It will print out something like:

pub   1024D/059DD5EB 2007-09-29
      Key fingerprint = 3E5C 0B3C 8987 79B9 A504 D7A5 463A E59D 059D D5EB
uid                  Daniel Holbach <dh@mailempfang.de>
…

In this case, the key ID is 059DD5EB , now please run

gpg –send-keys <KEY ID>

It will upload your _public_ portion of the key to keyservers which will sync the key among them. Once that’s done, you can tell Launchpad, which we use for all development about your shiny new gpg key - https://launchpad.net/people/+me/+editpgpkeys (you need a Launchpad account for this)

https://help.launchpad.net/YourAccount/ImportingYourPGPKey should help you if you run into any trouble