Ubuntu Developer Week was on some time back. I hung around for the start where Daniel Holbach who started things off with the “Getting Started with Ubuntu Development” IRC chat. Really good talk (chat) and lot of questions answered too (though I was more of the passive listener tonight). The problem, I felt, was that an IRC chat is very real-time and difficult to use as a reference when you actually get down to working on something. So, I thought it would be a good idea to blog about it. I hope all the descriptions etc are good and right.
If anyone wants to read the chat-logs you can find it here.
So, here goes!
The first page which you can use is the Ubuntu wiki page – UsingDevelopmentReleases. It has tonnes of info and links that you can use during your development time. The first thing you’ll need is an environment to develop in. A place where whatever crap you end up doing isn’t going to damage your happy Ubuntu installation. One of the things you can use is chroot
Installing chroot
Easy thing, this. Run these commands to get the installation done
sudo apt-get install chroot
sudo apt-get install debootstrap
If you haven’t already enabled “Source Code” and “Universe” in System → Software Sources → Ubuntu Software you can do that now.
Note: We’ll be dealing with some basic bug-fixes etc first. This is not going to be gnome centric (which is a natural assumption that many will have considering its Ubuntu)
Run the following command :
sudo apt-get install --no-install-recommends bzr-builddeb ubuntu-dev-tools fakeroot build-essential gnupg pbuilder debhelper
This will give you a bunch of tools that are going to be useful, generally (not just in these examples)
bzr-builddeb pulls in bzr, which is the short for Bazaar which we’ll use to get the source-codes for one or two examples.
ubuntu-dev-tools pulls in devscripts which 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
Let’s first set up our gpg key which we use to sign files for upload. More generally it is used to sign and encrypt mails, files or general text. We use it to indicate that WE were the last to touch a file and not somebody else and that ensures that only people who we know about get to upload packages.
If you have no gpg-key yet, run the following command :
gpg --gen-key
When you are doing this, it is completely fine if you stick to the defaults. You don’t have to comment, for example. 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. As said earlier: if you have a gpg key already, skip this step
If you need more information on gpg-keys you can look through the Gnu Privacy Guide which about everything in more detail.
Now we can set-up pbuilder.
Open an editor and edit the file ~/.pbuilderrc (create it if you don’t have it yet) and add the following content to the file:
COMPONENTS=”main universe multiverse restricted”
Save it and once you’re done, run the following command :
sudo pbuilder create
What does pbuilder do?
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 so 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
How does pbuilder work? It first gets the minimal packages for a base system and stores them in a tarball. Whenever you build a package it’ll untar the base tarball, then install whatever your current build requires, build it, then tear it all down again. Luckily it caches the packages.
Something else we can do in the meantime is if you use the bash shell, which is the default, please edit ~/.bashrc. At the end of it, add something like
DEBFULLNAME=”Your Name”
DEBEMAIL=”your.mail.id@provider.com”
Once you’re done editing ~/.bashrc, please run source ~/. bashrc (it’s only needed once)
QUESTION: Should these match the values we put into GPG?
A: 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.
(aside) General Fundas:
Ubuntu is very special in how it’s produced and how we all work. As you know it comes out every 6 months and that means we have a tight release schedule and everything we do and work on is defined by that schedule. Check this out for the current release schedule for maverick.
In that link, basically, green means: lots is allowed here, red means: almost nothing is allowed here.
In more detail,
– 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 changesThe focus is clearly: testing, testing, testing and fixing, fixing, fixing
So How do you get stuff in?
Only people who “we know” get to upload packages directly, as we said before. 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 applicationIt’s 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.
Now get the source of the hello package and run the command:
apt-get source hello
sudo pbuilder build hello_*.dsc
Now, pbuilder will work as explained earlier.
Note : .dsc has some metadata like checksums and the like. Not important right now.
You can check out the contents of /var/cache/pbuilder/result and it will contain the built hello.deb file.
End of Part 1 – There is no logical end here, but I don’t like very (extra) long posts.
I’m amazed that 
The need for such a tool is greater in Linux than in Windows considering you have a greater degree of freedom in configuring obscure files to make the OS perform the way you want it to. From that perspective, it has become quite a pain searching for files of something I had installed a long time ago. Also, I’ve been reading a few research papers of late and I’ve been making some notes in txt. ReFinding something is a nightmare if you can’t remember the filename.
Tracker is short for 
Google Desktop Search
Technically Possible 