GetStarted

Dev Week -- Getting Started with UbuntuDevelopment -- dholbach -- Mon, Aug 31st, 2009

Abridged and Edited Version

Note, some text reordered and modified for flow and context.

Introduction

My name is Daniel Holbach... any questions after the session, ideas for improvement, pieces of advice, nice comments and cheques, please send to dholbach at ubuntu dot com. I'll be your host for the first two sessions, which will be all about Getting Started with Ubuntu Development.

My aim for the session is to get your from "How can I help out? I can't code in C/C++" (a question I get very often) to "Ah, I understand things much better now, I know where to look things up and who to ask". So I'll cover a bunch of more general topics and help you set up a development environment.

Preparations

So as a first step, please enable Source code in System -> Administration -> Software Sources -> Ubuntu Software. Once that's done, you'll notice a lot of entries that start with deb-src in /etc/apt/sources.list. I'll explain why we need it a bit later on.

Afterwards, please run,

  •  sudo apt-get install --no-install-recommends ubuntu-dev-tools build-essential pbuilder dpkg-dev gnupg

it will install a bunch of very useful tools we're going to need for the session. Here is a description of the tools:

  • ubuntu-dev-tools contains scripts that are very useful for packaging and repetitive tasks (it also depends on devscripts, which has even more useful stuff).

  • build-essential is necessary to do the most common tasks having to do with compiling and building.

  • pbuilder is the perfect tool to build packages in a sane and reproducable way. It is a great tool to test-build a package in a separate and minimal environment.

  • dpkg-dev contains more tools for packaging.

  • gnupg is used to sign packages -- to identify them as our own work and make sure they weren't tampered with. You can also use it to encrypt and sign other files and emails.

Now please edit the file ~/.pbuilderrc (using gedit, vi, emacs, whatever you like best). Add the following line to it,

  •  COMPONENTS="main universe multiverse restricted"

and save it.

Now please run,

  •  sudo pbuilder create

it will set up a pbuilder instance for you which will take a while.

While that is running, let's create a GPG Key; if you have one already, you can lay back and relax. Please run,

  •  gpg --gen-key

See https://help.ubuntu.com/community/GnuPrivacyGuardHowto for more info, I won't go into too much detail; using the default should be fine for now. Give it your name and your preferred email address. That should be fine for now.

Once it's done, you can get your fingerprint and key id by running something like this:

  •  gpg --fingerprint your.name@email.com

Mine says something like:

  •  pub   1024D/059DD5EB 2007-09-29
           Schl.-Fingerabdruck = 3E5C 0B3C 8987 79B9 A504  D7A5 463A E59D 059D D5EB
     uid                  Daniel Holbach .......

059DD5EB is the key id.

Afterwards please run,

  •  gpg --send-keys '''KEYID'''

i.e. gpg --send-keys 059DD5EB. This will upload your GPG key to the servers, so other people can identify your files and your emails as yours. If you have a problem with gpg not having a default keyserver set, in that case please add --keyserver keyserver.ubuntu.com to the command.

As a next step, we need to upload it to Launchpad too. (If you have no Launchpad account yet, please visit https://launchpad.net/+login). You can add your GPG key to Launchpad by visiting https://launchpad.net/people/+me/+editpgpkeys.

Next we'll tell the development tools who we are. Just edit ~/.bashrc in your favorite editor and add something like this to the end of it:

  •  export DEBFULLNAME='Daniel Holbach'
     export DEBEMAIL='daniel.holbach@ubuntu.com'

then save it and run,

  •  source ~/.bashrc

That should be it for preparations right now. So what did we do,

  • Install a bunch of tools
  • Created a pbuilder instance (which might still be running for some of you)

  • Created a GPG key
  • Uploaded the key to keyservers and launchpad

Intro to Launchpad

Launchpad is used for everything in Ubuntu -- Translations of packages, Bug Reports for packages, Specifications of new Ubuntu features, Code branches, and packages are also built there. That plus our whole team organisation. The great thing about Launchpad is that it is written by awesome people and it is Open Source. Also... it's written in Python Smile :) .

We'll have a bunch of interesting Launchpad sessions too this week:

  • Using the LP API for fun and profit -- leonardr (Tue 1st Sep, 19:00 UTC)

  • Getting started with Launchpad development -- gmb (Wed 2nd Sep, 16:00 UTC)

  • Being productive with bzr and LP code hosting -- rockstar (Thu 3rd Sep, 19:00 UTC)

  • Hacking Soyuz to get your builds done -- noodles775, cprov and wgrant (Fri 4th Sep, 20:00 UTC)

A lot of other sessions will probably briefly cover Launchpad too.

Intro to the Ubuntu Development Process

I'll talk a bit about source packages and what we do with them, how code gets changed, when we change which pieces of Ubuntu, who you can talk to, where you can find out more, etc. Then we'll do some hands-on package building :).

So first of all, here's where you find more information: https://wiki.ubuntu.com/MOTU/GettingStarted. Bookmark the page! It links to all the important documents we have. Among them:

Ok, now let's have a look at https://wiki.ubuntu.com/ReleaseSchedule. It's a great way to understand more about Ubuntu Development if you want to know more about the different phases of the release.

This is the schedule of the karmic release, which we're working on right now -- it's due for October 29th.

In the first phase, the new release is created in Launchpad and the toolchain is set up, which means that the most important packages (like libc and gcc -- the compiler collection) are bootstrapped. (Bootstrapping is when the new toolchain is uploaded, you need to make sure the new gcc is built with the new libc6 and binutils, etc.) Afterwards, we start merging changes from Upstream and Debian (I'll go into more detail in a bit). And then UDS happens.

UDS is the Ubuntu Developer Summit where Ubuntu developers meet in real life to discuss and define new features. These often result into specifications, where we exactly describe why we want the feature, how it's going to work, its impact and its implementation strategy. (https://blueprints.launchpad.net/ubuntu should have a few you can take a look at.) Everybody is invited to attend UDS, so if you live close or are sponsored to go there, you can participate locally. If you can't, you can participate via VOIP and IRC.

Once the new features are all discussed and described in specifications, people work on their features, upload new versions of packages, and we import a log of packages from Debian (more on that in a bit). That all happens in the green part of https://wiki.ubuntu.com/ReleaseSchedule. Green doesn't mean "it's all great here an it all works"! It means that developers have a lot of freedom to work on things Smile :) .

If you want to participate, you need to run the new development release in some form. I say in some form because obviously you probably need your computer and can't have the kernel, libc, X or GNOME explode all the time Smile :) . https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases describes how to safely and sanely use the current development release.

Test-building a package for karmic is a good start; you definitely need to do this on karmic too: TESTING. That is why "test building on karmic" is not good enough. https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases explains how to use a virtual machine, a chroot, or a separate partition for your development work, so you don't hose the family computer Smile :) .

Ok, moving on in the release schedule...

Afterwards, we have Feature Freeze (which we're in karmic right now) where you need to get exceptions for uploading new upstream versions or other radical changes. At this time of the release some things might still be broken, but the features should at least be half-way there.

After that, we introduce more and more freeze dates: UI, kernel, documentation, translations, etc. One gets frozen every week so we get a very stable release that can be safely documented, translated and tested.

There is a number of upstream developers (which means software authors) that provide us with test suites and very often they are run during the build to directly find out if things got broken in the new release. There's tools like pbuilder for safe test-building and there's tools like lintian that can check your packaging for you.

Source Packages

Now let's get some a package and let's try to test build it.

Please run,

  •  apt-get source hello

if you have "Sources" enabled in Software Sources, this should work now. It will get the source package for the hello package.

There's the distinction between the source packages and the binary packages. What my Mom installs, the .deb files, are the binary packages which are a result of the build. What we work on as Ubuntu developers is the source packages.

In the case of hello (on karmic) this means the following files: hello_2.4-1.diff.gz, hello_2.4-1.dsc, hello_2.4.orig.tar.gz.

  • hello_2.4.orig.tar.gz means the original source code that was released by the software authors of hello for the version 2.4. The orig is important -- it means this tar.gz file didn't receive any changes at all, it's just as it was downloaded from the hello homepage (just renamed).

  • hello_2.4-1.diff.gz is the compressed set of changes that were applied by Debian (and Ubuntu) developers to make the source package build the Debian/Ubuntu way.

  • hello_2.4-1.dsc just contains meta data of the package like md5sums and so on.

So what does this mean "the debian/ubuntu way"? Some of you might have compiled source code already, where you manually build software by running,

  •  ./configure
     make
     sudo make install

The packaging process basically wraps around those build commands and enables us to apply the same build process to every kind of package. So it doesn't matter if it's a python program, a set of PHP modules, something written in C, or something to do with Perl. Also you add some meta information, like the package name, a description, etc.

In more detail... A regular application written in C will often require you to run something like ./configure; make; make install; etc. A Python application that uses distutils might need something like invocations of python ./setup.py .... Sometimes for a package to work afterwards (e.g. some simple scripts) it will be enough to just copy them where they belong.

The package build process can be divided into steps like: configuration, compilation, installation, something that happens post-installation, and so on. Think of it as a "meta build process". That process is specified in the debian policy and we make use of that. The great thing about this standardisation is: our tools all treat source packages the same way, no matter what weird way they work internally.

The session Packaging from scratch by Laney on Friday will talk about that in more detail. Also Learning from mistakes - REVU reviewing best practices by mok0 on Thursday will have useful tips.

So what apt-get source (or more specifically, dpkg-source -x *.dsc) did was:

  • Unpack hello_2.4.orig.tar.gz

  • Unpack and apply the patch with our changes (hello_2.4-1.diff.gz).

So you should be able to see the hello-2.4 directory (or hello-2.3 if you're on an older version). This directory should contain a debian/ directory, which contains all the packaging.

  •  $ ls hello-2.4/debian/
     changelog  control  copyright  postinst  prerm  rules  watch

I won't explain every last detail now, just very quickly.

  • changelog: descriptions of all the packaging changes (one new entry per new version that was uploaded to the archive).

  • control: information about the source package (who maintains it, where's the homepage, which packages are necessary to build it, etc.) and the resulting binary package(s).

  • copyright: licensing and copyright information of the software.

  • rules: how is the package build, how does the meta build process work.

we can safely ignore the others for now.

Now let's test-build the package. If your pbuilder setup succeeded, you just run the following,

  •  sudo pbuilder build hello_2.4-1.dsc

If it works out, you should be able to have a look at /var/cache/pbuilder/result/hello_*.deb afterwards. This should work:

  •  less /var/cache/pbuilder/result/hello_*.deb

which should show you the contents of the package, its size and dependencies, etc. If you have a look at the build log, you will see what happened:

  • the separate build environment was set up, then some additional packages installed.
  • ./configure was run

  • the actual compilation of the source code happened
  • some files were installed
  • they were all glued together in /var/cache/pbuilder/result/hello_*.deb

  • the build environment was torn down.

The fine thing about pbuilder is that it will store all the packages that are necessary to build a package, so you don't need to download them over and over again. (You can also set up pbuilder to share the same cache as apt; https://wiki.ubuntu.com/PbuilderHowto should have more information on the topic.) (FYI, pbuilder-dist is a fine tool to test-build packages for various Ubuntu and Debian releases.)

If packages need an update, you run,

  •  sudo pbuilder update

which is similar to doing an apt-get update.

Building a package does not automatically install it. You have to explicitly install the package, by running,

  •  sudo dpkg -i /var/cache/pbuilder/result/hello_*.deb

and then to run it, run,

  •  hello

To completely clean up pbuilder and the development environment,

  • deinstall packages that we installed
  • remove ~/.pbuilderrc

  • remove /var/cache/pbuilder

But more practically, just use a virtual machine.

Best check out https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases, which explains how to have a separate, up-to-date development environment. (You can also use this package build process for Debian.)

Ubuntu Development and Developers

So, how does Ubuntu Development work? What do people do with those .dsc, .diff.gz and .orig.tar.gz files? Basically for every change that is done to a package, a new source package must be uploaded to the Launchpad build servers. That's where the gpg key comes in, if you're not part of the team (I'll get to that in a sec), it will reject your changes. The same applies for Launchpad Personal Package Archives (https://help.launchpad.net/Packaging/PPA).

You can think of it as a primitive (sorry everybody) version control system. Developer A makes a change and uploads version 2.4-2 of hello, and I can get it via apt-get source hello later on and improve it some more if I like. There are efforts going on to make more use of distributed revision control (using Bazaar on Launchpad) and Mr. James Westby will talk about that later in the week (Friday, 4th September, 18:00 UTC -- Fixing an Ubuntu bug using Bazaar).

So how would you go about sending in changes now that you're not part of the team yet? Easy -- come to tomorrow's sessions Fixing small bugs in Ubuntu and learn how to produce patches. Once you have the patch, you attach it to a bug report and subscribe the reviewers team. They'll give you a review and some advice and upload the change for you once it's all good. Basically, they'll download the source package, apply your changes, sign it with their gpg key and upload it for you. To find out more detail about the reviewers team and how to get stuff uploaded at: https://wiki.ubuntu.com/SponsorshipProcess.

Once the reviewers are happy with your general work and tired of uploading and reviewing myriads of changes for you, they'll tell you that and you can send your application for upload rights Smile :) . https://wiki.ubuntu.com/UbuntuDevelopers explains the process.

(What if two users happen to update at the same time on Launchpad? The collisions happen every now and then, but Launchpad will just use the one that was milliseconds before and throw away the other Smile :) .)

That roughly covers how Ubuntu works. There's the release schedule with freeze dates, there's people working with source packages, there's bug reports and people attaching patches to them. There's packages getting built, downloaded and tested.

But that doesn't explain how developers interact. There's mailing lists and IRC. https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu and #ubuntu-motu should be interesting for you because these channels contain the most awesome and friendly people that can help you out. There's lots more mailing lists: https://lists.ubuntu.com/ and lots more IRC channels: https://help.ubuntu.com/community/InternetRelayChat, but try to take one step at a time; it can be a bit overwhelming Smile :) .

Now that we know how developers interact, one thing is very important: always document changes you are about to make as good as you can. We have people living in various parts on Earth, speaking different languages and having different skill sets. As we maintain all packages together as one big team, it's important that other developers don't have to second guess what you might have meant. Also in 6 months time, you probably don't want to second guess your own patches or documentation Smile :) .

If you want to participate in specific teams in Ubuntu, check out https://wiki.ubuntu.com/Teams for more information.

Patches and Other Projects

Ok... Speaking of patches and developers: we're not alone in the open source world. We inherit a great deal of good stuff from the Debian project and other projects. If we make changes, we want to make sure to contribute them back to Debian, so let's take a quick look back at the hello example. 2.4-1 is the version in karmic. This means:

  • 2.4 is the release that was done by the authors of hello on their homepage.

  • -1 means that one revision of 2.4 was done in Debian and we inherited that. debian/changelog has more information on what happened there.

If I was to do a change for karmic, the new version string would be: 2.4-1ubuntu1, meaning: still 2.4 upstream release, one (inherited) debian revision, one Ubuntu change.

This also means that in the new Ubuntu release (karmic+1) we can't just copy (we call it 'sync') the package from Debian, as we might overwrite the changes that I did in 2.4-1ubuntu1. If there was a 2.5-1 in Debian, we'd need to very closely check if we can just overwrite my changes, or if I need to merge the manually into the 2.5-1 Debian version (and thus get 2.5-1ubuntu1). To be able to sync as much as possible and share the same codebase all over it's necessary to send patches upstream.

On Wednesday we'll have a session called Bug lifecycle, Best practices, Workflow, Tags, Upstream, Big picture by jcastro and pedro_ who will talk about that some more.

What happens with package numbering when Ubuntu brings out a newer upstream version before Debian does, and then Debian catches up? So let's say Debian is still on 2.4-1 and we discover there's a new release out by the hello upstream guys. We'd call it 2.5-0ubuntu1 to indicate: it's upstream 2.5, we didn't get a revision of it from Debian, but have the first revision of it in Ubuntu.

For version ordering, 2.4-1 comes before 2.10-1. To be on the safe side, you can do this:

  •  $ dpkg --compare-versions 2.10-1 gt 2.4-1 && echo TRUE
     TRUE

dpkg is always authoritative on package versions. (The command above checks if 2.10-1 is greater than 2.4-1, and prints TRUE if it's true.)

What happens with backports? How does that process work and when does a package get backported? Once karmic is frozen, no uploads will happen to karmic any more. Afterwards, only uploads to karmic-security, karmic-updates, and karmic-backports are accepted. Effectively testing for regressions -- sbeattie on Thursday will have more information on that. https://wiki.ubuntu.com/SRU also explains it in more detail. (This concerns all releases, LTS or not.)

What is preferred -- create a Debian package and wait for Ubuntu to sync with Debian, or create an Ubuntu package directly? It all depends on the release schedule. If we're a week away from release and the fix is critical, we might ask somebody from upstream for advice, but we won't block on them if we know that we need that fix. https://wiki.ubuntu.com/Upstream has more info on our collaboration with upstreams.

Conclusion

As last tips I'd like to give you:

I really hope to see all of you during the great sessions we have this week and hope to see you all as Ubuntu contributors really really soon. Make me proud! Smile :)

Thanks everybody -- have a great Ubuntu Developer Week!

IRC Logs Transcript

(12:02:03 PM) dholbach: My name is Daniel Holbach... any questions after the session, ideas for improvement, pieces of advice, nice comments and cheques please to dholbach at ubuntu dot com.
(12:02:21 PM) dholbach: I'll be your host for the first two sessions which will be all about "Getting Started with Ubuntu Development".
(12:02:22 PM) credobyte: & me
(12:02:30 PM) rish: ok, dholbach let's start
(12:02:37 PM) dholbach: so let's first dive into a bit of organisational stuff
(12:02:51 PM) dholbach: I noticed a bunch of people I already know but there's a lot of new "faces" here too
(12:03:24 PM) dholbach: We're around 300 people in here already, which is why ALL QUESTIONS and ALL CHATTER go to #ubuntu-classroom-chat instead of #ubuntu-classroom
(12:03:33 PM) dholbach: else the logs will be totally unreadable afterwards
(12:03:54 PM) the-dude: will logs be saved?
(12:03:56 PM) tiax: won't you set +m?
(12:04:00 PM) dholbach: the-dude: yes
(12:04:06 PM) dholbach: so if you're not in #ubuntu-classroom-chat yet, please join the channel now
(12:04:34 PM) robbbb left the room.
(12:04:35 PM) ***popey hugs dholbach 
(12:04:52 PM) dholbach: in #ubuntu-classroom-chat please prefix your questions with "QUESTION: "
(12:05:08 PM) dholbach: ie: "QUESTION: Do you like doing Ubuntu Development?"
(12:05:35 PM) dholbach: also for those not fluent in English, we have irc channels where you can ask questions in your language, they will be translated into English for you
(12:05:40 PM) dholbach:  - Catalan: #ubuntu-classroom-chat-ca
(12:05:40 PM) dholbach:  - Danish:  #ubuntu-nordic-dev
(12:05:40 PM) dholbach:  - Finnish: #ubuntu-fi-devel
(12:05:40 PM) dholbach:  - German:  #ubuntu-classroom-chat-de
(12:05:40 PM) dholbach:  - Spanish: #ubuntu-classroom-chat-es
(12:05:41 PM) dholbach:  - French:  #u-classroom
(12:05:54 PM) dholbach: if there's other channels for other languages, please announce them in #ubuntu-classroom-chat
(12:06:21 PM) dholbach: Alright... another piece of advice:
(12:06:38 PM) dholbach: https://wiki.ubuntu.com/UbuntuDeveloperWeek lists the timetable and links to a beautiful brochure that has more information
(12:06:54 PM) dholbach: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Sessions should tell you if you need to prepare for any session
(12:07:10 PM) dholbach: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/glossary has some useful glossary for abbreviations and stuff
(12:08:01 PM) dholbach: alright... that should be everything organisational for now... just bookmark https://wiki.ubuntu.com/UbuntuDeveloperWeek and you'll be fine for this week :-)
(12:08:07 PM) dholbach: so let's get the session started
(12:09:26 PM) dholbach: my aim for the session is to get you from "How can I help out? I can't code in C/C++." (a question I get very often) to "Ah, I understand things much better now, I know where to look things up and who to ask."
(12:09:50 PM) dholbach: so I'll cover a bunch of more general topics and help you set up a development environment
(12:11:05 PM) dholbach: so as a first step, please enable "Source code" in System -> Administration -> Software Sources -> Ubuntu Software
(12:11:59 PM) dholbach: Once that's done, you'll notice a lot of entries that start with deb-src in /etc/apt/sources.list
(12:12:19 PM) dholbach: I'll explain why we need it a bit later on
(12:12:27 PM) dholbach: afterwards, please run
(12:12:29 PM) dholbach:    sudo apt-get install --no-install-recommends ubuntu-dev-tools build-essential pbuilder
(12:12:45 PM) dholbach: it will install a bunch of very useful tools we're going to need for the session
(12:13:15 PM) dholbach: ubuntu-dev-tools contains scripts that are very useful for packaging and repetitive tasks (it also depends on devscripts which has even more useful stuff)
(12:13:41 PM) dholbach: build-essential is necessary to do the most common tasks having to do with compiling and building
(12:14:15 PM) dholbach: pbuilder is the perfect tool to build packages in a sane and reproducable way
(12:15:00 PM) dholbach: now please edit the file    ~/.pbuilderrc    (gedit, vi, emacs, whatever you like best)
(12:15:16 PM) dholbach: add the following line to it:
(12:15:17 PM) dholbach: COMPONENTS="main universe multiverse restricted"
(12:15:19 PM) dholbach: and save it
(12:15:28 PM) dholbach: now please run:
(12:15:29 PM) dholbach:    sudo pbuilder create
(12:15:50 PM) dholbach: it will set up a pbuilder instance for you which will take a while
(12:16:06 PM) dholbach: I forgot, please install gnupg too:
(12:16:09 PM) dholbach:   sudo apt-get install gnupg
(12:17:10 PM) dholbach: <_Fauchi95_> QUESTION: Do I need to use pbuilder or is that optional?
(12:17:57 PM) dholbach: _Fauchi95_: pbuilder is a great tool to test-build a package in a separate and minimal environment - it's a great way to test the build
(12:18:15 PM) dholbach: it's by no means a must, but I'll get back to the topic of testing in a bit
(12:18:43 PM) dholbach: ok... while that's running, let's create a GPG Key - if you have one already you can lay back and relax
(12:18:50 PM) dholbach: Please run
(12:18:53 PM) dholbach:   gpg --gen-key
(12:19:33 PM) dholbach: we use GPG keys to sign packages to identify them as our own work and make sure they weren't tampered with
(12:19:46 PM) dholbach: you can also use it to encrypt and sign other files and emails
(12:20:02 PM) dholbach: https://help.ubuntu.com/community/GnuPrivacyGuardHowto has more info and I won't go into too much detail, using the defaults should be fine for now
(12:20:41 PM) dholbach: give it your name and your preferred email address, that should be fine for now
(12:21:59 PM) dholbach: once it's done, you can get your fingerprint and key id by running something like this:
(12:22:08 PM) dholbach:    gpg --fingerprint your.name@email.com
(12:22:27 PM) dholbach: mine says something like:
(12:22:31 PM) dholbach: pub   1024D/059DD5EB 2007-09-29
(12:22:31 PM) dholbach:       Schl.-Fingerabdruck = 3E5C 0B3C 8987 79B9 A504  D7A5 463A E59D 059D D5EB
(12:22:31 PM) dholbach: uid                  Daniel Holbach .......
(12:22:40 PM) dholbach: 059DD5EB is the key id
(12:23:49 PM) dholbach: Afterwards please run
(12:23:58 PM) dholbach:    gpg --send-keys KEYID
(12:24:07 PM) dholbach: ie: gpg --send-keys 059DD5EB
(12:24:28 PM) dholbach: this will upload your gpg key to the servers, so other people can identify your files and your emails as yours
(12:24:55 PM) dholbach: as a next step, we need to upload it to Launchpad too
(12:25:05 PM) dholbach: (if you have no Launchpad account yet, please visit https://launchpad.net/+login)
(12:26:26 PM) dholbach: it seems like some people have a problem with gpg not having a default keyserver set, in that case, please add  --keyserver keyserver.ubuntu.com
(12:26:54 PM) dholbach: you can add your GPG key to Launchpad by visiting: https://launchpad.net/people/+me/+editpgpkeys
(12:27:47 PM) dholbach: ok, that should be it for preparations right now
(12:27:54 PM) dholbach: so what did we do
(12:27:59 PM) dholbach:  - install a bunch of tools
(12:28:11 PM) dholbach:  - created a pbuilder instance (which might be still running for some of you)
(12:28:15 PM) dholbach:  - created a GPG key
(12:28:29 PM) dholbach:  - uploaded the key to keyservers and launchpad
(12:29:12 PM) dholbach: ok... so what do we do with Launchpad
(12:30:05 PM) dholbach: Launchpad is used for everything in Ubuntu - Translations of packages, Bug Reports for packages, Specifications of new Ubuntu features, Code branches, and packages are also built there
(12:30:12 PM) dholbach: that plus our whole team organisation
(12:30:32 PM) dholbach: the great thing about Launchpad is that it is written by awesome people and it is Open Source
(12:30:36 PM) dholbach: also... it's written in Python :)
(12:30:58 PM) dholbach: We'll have a bunch of interesting Launchpad sessions too this week:
(12:31:13 PM) dholbach:  -  Using the LP API for fun and profit -- leonardr (Tue 1st Sep, 19:00 UTC)
(12:31:29 PM) dholbach:  -  Getting started with Launchpad development -- gmb  (Wed 2nd Sep, 16:00 UTC)
(12:31:54 PM) dholbach:  -  Being productive with bzr and LP code hosting - rockstar (Thu 3rd Sep, 19:00 UTC)
(12:32:08 PM) dholbach:  -  Hacking Soyuz to get your builds done -- noodles775, cprov and wgrant (Fri 4th Sep, 20:00 UTC)
(12:32:22 PM) dholbach: a lot of other sessions will probably briefly cover Launchpad too
(12:33:39 PM) dholbach: <anurag213> Question:Not enough random bytes available.  Please do some oth
(12:34:03 PM) dholbach: anurag213: just let it sit there for a while - gnupg is getting more entrophy and random numbers from your machine
(12:34:28 PM) dholbach: ok, next we'll tell the development tools who we are
(12:34:41 PM) dholbach: just edit  ~/.bashrc  in your favourite editor
(12:34:46 PM) dholbach: and add something like this to the end of it:
(12:34:52 PM) dholbach:    export DEBFULLNAME='Daniel Holbach'
(12:34:52 PM) dholbach:    export DEBEMAIL='daniel.holbach@ubuntu.com'
(12:34:59 PM) dholbach: then save it
(12:35:08 PM) dholbach: and run    source ~/.bashrc
(12:35:47 PM) dholbach: alright... that should be it for now
(12:35:50 PM) dholbach: so what's next
(12:36:27 PM) dholbach: I'll talk a bit about source packages and what we do with them, how code gets changed, when we change which pieces of Ubuntu, who you can talk to, where you can find out more, etc. :)
(12:36:39 PM) dholbach: then we'll do some hands-on package building :-)
(12:37:03 PM) dholbach: so first of all, here's where you find more information:
(12:37:04 PM) dholbach:  https://wiki.ubuntu.com/MOTU/GettingStarted
(12:37:17 PM) dholbach: bookmark the page! it links to all the important documents we have
(12:37:20 PM) dholbach: among them:
(12:37:27 PM) dholbach:   - https://wiki.ubuntu.com/PackagingGuide
(12:37:50 PM) dholbach:      which has a lot of information about packaging in general
(12:38:17 PM) dholbach:      especially https://wiki.ubuntu.com/PackagingGuide/Recipes where you can find out how to use the tools easily
(12:38:55 PM) dholbach:      there's also https://wiki.ubuntu.com/MOTU/Videos which has a bunch of videos which talk about packaging, updating packages, patching stuff, etc.
(12:39:36 PM) dholbach:   -  https://wiki.ubuntu.com/UbuntuDevelopment is important too because it explains how Ubuntu Development generally works, processes, who is responsible for what and so on
(12:40:01 PM) dholbach:   - https://wiki.ubuntu.com/Packaging/Training invites you to Packaging Training IRC sessions which happen every Thursday
(12:40:13 PM) dholbach: the next one is going to be: Thursday 3rd September, 6:00 UTC, Ubuntu Development Q&A... with me :-)
(12:41:30 PM) dholbach: ok, now let's have a look at https://wiki.ubuntu.com/ReleaseSchedule
(12:41:50 PM) dholbach: it's a great way to understand more about Ubuntu Development if you know more about the different phases of the release
(12:42:13 PM) dholbach: this is the schedule of the karmic release which we're working on right now - it's due for October 29th
(12:43:16 PM) dholbach: in the first phase the new release is created in Launchpad and the toolchain is set up which means that the most important packages (like libc and gcc, the compiler collection) are bootstrapped
(12:43:35 PM) dholbach: afterwards we start merging changes from Upstream and Debian (I'll go into more detail in a bit)
(12:43:40 PM) dholbach: and then UDS happens
(12:43:58 PM) dholbach: UDS is the Ubuntu Developer Summit where Ubuntu developers meet in real life to discuss and define new features
(12:44:27 PM) dholbach: these often result into specifications where we exactly describe why we want the feature, how it's going to work, its impact and its implementation strategy
(12:44:39 PM) dholbach: https://blueprints.launchpad.net/ubuntu should have a few you can take a look at
(12:44:46 PM) dholbach: <alourie|vm> dholbach: how can a person participate in UDS?
(12:45:14 PM) dholbach: alourie|vm: everybody is invited to attend UDS, so if you live close or are sponsored to go there you can participate locally
(12:45:22 PM) dholbach: if you can't, you can participate via VOIP and IRC
(12:45:37 PM) dholbach: <gotunandan> QUESTION : what do you mean by bootstrap ?
(12:46:40 PM) dholbach: gotunandan: when the new toolchain is uploaded, you need to make sure the new gcc is built with the new libc6 and binutils, etc. - I unfortunately don't have much time to discuss it here, but #ubuntu-toolchain might be a good place to discuss it further
(12:47:28 PM) dholbach: once the new features are all discussed and described in specifications people work on their features, upload new version of packages and we import a lot of packages from Debian
(12:47:33 PM) dholbach: (more on that in a bit)
(12:47:57 PM) dholbach: that all happens in the "green" part of     https://wiki.ubuntu.com/ReleaseSchedule
(12:48:11 PM) dholbach: "green" doesn't mean "it's all great here and it all works"!
(12:48:25 PM) dholbach: it means that developers have a lot of freedom to work on things :)
(12:48:47 PM) dholbach: if you want to participate you need to run the new development release IN SOME FORM
(12:49:08 PM) dholbach: I say "in some form" because obviously you probably need your computer and can't have the kernel, libc, X or GNOME explode all the time :-)
(12:49:21 PM) dholbach: https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases describes how to safely and sanely use the current development release
(12:49:38 PM) dholbach: <trothigar> QUESTION: for packaging can you just run pbuilder for the development release?
(12:49:46 PM) dholbach: trothigar: good question - just what I wanted to talk about :)
(12:49:54 PM) dholbach: the answer is no
(12:50:07 PM) dholbach: test-building a package for karmic is a good start
(12:50:23 PM) dholbach: but you definitely need to do this on karmic too:
(12:50:23 PM) dholbach:   _____ _____ ____ _____ ___ _   _  ____ _
(12:50:24 PM) dholbach:  |_   _| ____/ ___|_   _|_ _| \ | |/ ___| |
(12:50:24 PM) dholbach:    | | |  _| \___ \ | |  | ||  \| | |  _| |
(12:50:24 PM) dholbach:    | | | |___ ___) || |  | || |\  | |_| |_|
(12:50:24 PM) dholbach:    |_| |_____|____/ |_| |___|_| \_|\____(_)
(12:50:41 PM) dholbach: which is why just "test building on karmic" is not good enough
(12:51:04 PM) dholbach: https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases explains how to use a virtual machine, a chroot or a separate partition for your development work, so you don't hose the family computer :)
(12:51:24 PM) dholbach: ok, moving on in the release schedule:
(12:51:53 PM) dholbach: afterwards we have Feature Freeze (which we're in in karmic right now) where you need to get exceptions for uploading new upstream versions or other radical changes
(12:52:08 PM) dholbach: at this time of the release some things might still be broken but the features should at least be half-way there
(12:52:54 PM) dholbach: after that we introduce more and more freeze dates: UI, kernel, documentation, translations, etc.
(12:53:11 PM) dholbach: one gets frozen every week so we get a very stable release that can be safely documented, translated and tested
(12:53:18 PM) dholbach: <slacker_nl> QUESTION: are there automated testtools for package testing, eg tests for regression testing? or should that be provided by upstream?
(12:53:23 PM) dholbach: slacker_nl: great question
(12:53:59 PM) dholbach: there's a number of upstream developers (which means software authors) that provide us with test suites and very often they are run during the build to directly find out if things got broken in the new release
(12:54:33 PM) dholbach: there's tools like pbuilder for safe test-building and there's tools like lintian that can check your packaging for you
(12:55:48 PM) dholbach: ok... let's take a quick 5 minute break and we can get our hands dirty afterwards
(12:55:58 PM) dholbach: for all of you that need a new cup of tea or a drink or need to nip to the loo
(12:56:05 PM) dholbach: see you in just a bit :-)
(01:00:22 PM) dholbach: alright... let's kick off part 2
(01:00:56 PM) dholbach: for all of you who just arrived: you can ask questions in #ubuntu-classroom-chat (please prefix with QUESTION:), logs will be available afterwards on https://wiki.ubuntu.com/UbuntuDeveloperWeek
(01:01:39 PM) dholbach: Ok... now let's get some source package and let's try to test build it
(01:01:42 PM) dholbach: please run
(01:01:43 PM) dholbach:    apt-get source hello
(01:02:00 PM) dholbach: if you have "Sources" enabled in Software Sources this should work now
(01:02:05 PM) dholbach: what it does it the following
(01:02:46 PM) dholbach: it will get the source package for the 'hello' package
(01:02:58 PM) dholbach: there's the distinction between the source packages and the binary packages
(01:03:16 PM) dholbach: what my Mom installs, the .deb files are the binary packages which are a result of the build
(01:03:24 PM) dholbach: what we work on as Ubuntu developers is the source packages
(01:03:46 PM) dholbach: in the case of hello (on karmic) this means the following files:
(01:03:48 PM) dholbach:    hello_2.4-1.diff.gz  hello_2.4-1.dsc  hello_2.4.orig.tar.gz
(01:04:46 PM) dholbach: hello_2.4.orig.tar.gz means: the original source code that was released by the software authors of 'hello' in the version 2.4
(01:05:12 PM) dholbach: the 'orig' is important - it means: this tar.gz file didn't receive any changes at all, it's just as it was downloaded from the hello homepage
(01:05:16 PM) dholbach: (just renamed)
(01:05:56 PM) dholbach: hello_2.4-1.diff.gz is the compressed set of changes that were applied by Debian (and Ubuntu) developers to make the source package build the Debian/Ubuntu way
(01:06:53 PM) dholbach: so what does this mean "the debian/ubuntu way"?
(01:07:15 PM) dholbach: some of you might have compile source code already, where you manually build software by running:
(01:07:25 PM) dholbach: ./configure    make     sudo make install
(01:07:57 PM) dholbach: the packaging process basically wraps around those build commands and enables us to apply the same build process to every kind of package
(01:08:17 PM) dholbach: so it doesn't matter if it's a python program, a set oh PHP modules, something written in C or something to do with Perl
(01:08:35 PM) dholbach: also you add some meta information like the package name, a description, etc.
(01:09:06 PM) dholbach: The session "Packaging from scratch" -- Laney on Friday will talk about that in more detail
(01:09:23 PM) dholbach: also "Learning from mistakes - REVU reviewing best practices" -- mok0  on Thursday  will have useful tips
(01:09:40 PM) dholbach: <[BIOS]Dnivra> QUESTION: Why is dpkg-dev needed? I get an error it's not installed. isn't it available in the ubuntu repository?
(01:09:43 PM) dholbach: sorry, please run
(01:09:47 PM) dholbach:    sudo apt-get install dpkg-dev
(01:09:55 PM) dholbach: it's needed too, I thought it would be pulled in
(01:10:03 PM) dholbach: just run
(01:10:08 PM) dholbach:      dpkg-source -x *.dsc
(01:10:12 PM) dholbach: afterwards and you'll be fine
(01:10:18 PM) dholbach: I'll get to the purpose of it in just a bit
(01:11:09 PM) dholbach: <[BIOS]Goo> QUESTION:Could you elucidate  "wraps around those build commands"
(01:11:17 PM) dholbach: [BIOS]Goo: ok, let's go into some more detail
(01:11:58 PM) dholbach: so a regular application written in C will often require you to run something like ./configure; make; make install; etc.
(01:12:30 PM) dholbach: a python application that uses distutils might need something like invocations of    python ./setup.py ....
(01:12:51 PM) dholbach: sometimes for a package to work afterwards (some simple scripts) it will be enough to just copy them where they belong
(01:13:30 PM) dholbach: the package build process can be divided into steps like configuration, compilation, installation, something that happens post-installation and so on
(01:13:36 PM) dholbach: think of it as a "meta build process"
(01:13:57 PM) dholbach: that process is specified in the debian policy and we make use of that
(01:14:26 PM) dholbach: the great thing about this standardisation is: our tools all treat source packages the same way, no matter what weird way they work internally
(01:14:41 PM) dholbach: moving on :)
(01:15:04 PM) dholbach: hello_2.4-1.dsc just contains meta data of the package like md5sums and so on
(01:15:53 PM) dholbach: so what apt-get source (or  more specifically dpkg-source -x *.dsc) did was:
(01:16:02 PM) dholbach:  - unpack hello_2.4.orig.tar.gz
(01:16:15 PM) dholbach:  - unpack and apply the patch with our changes hello_2.4-1.diff.gz
(01:16:25 PM) dholbach: so you should be able to see the hello-2.4 directory
(01:16:34 PM) dholbach: (or hello-2.3 if you're on an older version)
(01:16:54 PM) dholbach: this directory should contain a debian/ directory which basically contains all the packaging
(01:17:07 PM) dholbach: daniel@miyazaki:~$ ls hello-2.4/debian/
(01:17:07 PM) dholbach: changelog  control  copyright  postinst  prerm  rules  watch
(01:17:07 PM) dholbach: daniel@miyazaki:~$
(01:17:17 PM) dholbach: I won't explain every last detail now, just very quickly
(01:17:36 PM) dholbach:  - changelog: descriptions of all the packaging changes (one new entry per new version that was uploaded to the archive)
(01:18:01 PM) dholbach:  - control: information about the source package (who maintains it, where's the homepage, which packages are necessary to build it, etc.) and the resulting binary package(s)
(01:18:14 PM) dholbach:  - copyright: licensing and copyright information of the software
(01:18:27 PM) dholbach:  - rules: how is the package build, how does the meta build process work
(01:18:32 PM) dholbach: we can safely ignore the others for now
(01:18:58 PM) dholbach: alright... now let's test-build the package
(01:19:07 PM) dholbach: if your pbuilder setup succeeded, you just run the following
(01:19:14 PM) dholbach:     sudo pbuilder build hello_2.4-1.dsc
(01:19:53 PM) dholbach: if it works out, you should be able to have a look at /var/cache/pbuilder/result/hello_*.deb afterwards
(01:20:03 PM) dholbach: this should work
(01:20:05 PM) dholbach:    less /var/cache/pbuilder/result/hello_*.deb
(01:20:43 PM) dholbach: this will show you the contents of the package, its size and dependencies, etc.
(01:21:15 PM) dholbach: if you have a look at the build log you will see what happened there:
(01:21:40 PM) dholbach: first the separate build environment was set up, then some additional packages installed
(01:22:25 PM) dholbach: then ./configure was run, then the actual compilation of the source code happened, then some files were installed and then they were all glued together in /var/cache/pbuilder/result/hello_*.deb, then the build environment torn down again
(01:22:41 PM) dholbach: the fine thing about pbuilder is that it will store all the packages that are necessary to build a package
(01:22:49 PM) dholbach: and you don't need to download them over and over again
(01:23:33 PM) dholbach: <alourie|vm> dholbach: QUESTION: what if packages need an update?
(01:23:46 PM) dholbach: alourie|vm: you run    sudo pbuilder update   (similar to apt-get update)
(01:23:54 PM) dholbach: <trothigar> QUESTION: presumably the build deps are downloaded as binaries. Does pbuilder share the same cache as apt?
(01:23:59 PM) dholbach: trothigar: you can set it up that way
(01:24:10 PM) dholbach: https://wiki.ubuntu.com/PbuilderHowto should have more information on the topic
(01:25:04 PM) dholbach: it came up in -chat a couple of times, so here goes:
(01:25:06 PM) dholbach:   <RainCT> penguin42: Yeah. Using pbuilder-dist (from ubuntu-dev-tools) is a great way to achieve that
(01:25:22 PM) dholbach: pbuilder-dist is a fine tool to test-build packages for various ubuntu and debian releases
(01:25:29 PM) dholbach: talk to RainCT to find out more about it :)
(01:25:57 PM) dholbach: ok... so how does Ubuntu Development work? what do people do with those .dsc .diff.gz and .orig.tar.gz files
(01:26:37 PM) dholbach: basically for every change that is done to a package a new source package must be uploaded to the Launchpad build servers
(01:26:59 PM) dholbach: that's where the gpg key comes in, if you're not part of the team (I'll get to that in a sec), it will reject your changes
(01:27:20 PM) dholbach: the same applies for Launchpad Personal Package Archives (https://help.launchpad.net/Packaging/PPA)
(01:27:45 PM) dholbach: you can think of it as a primitive (sorry everybody) version control system
(01:28:16 PM) dholbach: Developer A makes a change and uploads version 2.4-2 of hello
(01:28:33 PM) dholbach: and I can get it via   apt-get source hello   later on and improve it some more if I like
(01:29:08 PM) dholbach: there are efforts going on to make more use of distributed revision control (using Bazaar on Launchpad) and Mr James Westby will talk about that later in the week
(01:29:09 PM) dholbach: Friday 4th September, 18:00 UTC - Fixing an Ubuntu bug using Bazaar -- james_w
(01:29:51 PM) dholbach: so how would you go about sending in changes now that you're not part of the team yet
(01:30:24 PM) dholbach: easy: come to tomorrow's session "Fixing small bugs in Ubuntu" and learn how to produce patches
(01:30:40 PM) dholbach: once you have the patch, you attach it to a bug report and subscribe the reviewers team
(01:31:01 PM) dholbach: they'll give you a review and some advice and upload the change for you once it's all good
(01:31:17 PM) dholbach: basically they'll download the source package, apply your changes, sign it with they gpg key and upload it for you
(01:31:26 PM) dholbach: <msp301> QUESTION: what would happen in the case that two users happen to update at the same time on Launchpad??
(01:31:46 PM) dholbach: msp301: those collisions happen every now and then, Launchpad will just use the one that was milliseconds before and throw away the other :)
(01:31:54 PM) dholbach: <alourie|vm> dholbach: QUESTION: how do we prepare patches?
(01:32:09 PM) dholbach: alourie|vm: tomorrow, 16:00 UTC, this place :-)
(01:32:38 PM) dholbach: find more detail about the reviewers team and how to get stuff uploaded at: https://wiki.ubuntu.com/SponsorshipProcess
(01:33:20 PM) dholbach: once the reviewers are happy with your general work and get tired of uploading and reviewing myriads of changes for you, they'll tell you that and you can send your application for upload rights :-)
(01:33:31 PM) dholbach: https://wiki.ubuntu.com/UbuntuDevelopers explains the process
(01:33:59 PM) dholbach: ok... that roughly explains how Ubuntu works
(01:34:25 PM) dholbach: there's the release schedule with freeze dates, there's people working with source packages, there's bug reports and people attaching patches to them
(01:34:33 PM) dholbach: there's packages getting built, downloaded and tested
(01:34:42 PM) dholbach: but that doesn't explain how developers interact
(01:34:47 PM) dholbach: there's mailing lists and IRC
(01:35:08 PM) dholbach: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu and #ubuntu-motu should be interesting for you
(01:35:23 PM) dholbach: because these channels contain the most awesome and frienly people that can help you out
(01:35:42 PM) dholbach: there's lots more mailing lists: https://lists.ubuntu.com/
(01:35:56 PM) dholbach: and there's lots more irc channels: https://help.ubuntu.com/community/InternetRelayChat
(01:36:02 PM) dholbach: but try to take one step at a time :-)
(01:36:06 PM) dholbach: it can be a bit overwhelming :)
(01:36:15 PM) dholbach: <bogor> QUESTION: Does building package in my pc will have it installed in my machine. If yes then how do i uninstall it if somethings goes wrong?
(01:36:28 PM) dholbach: bogor: no, you have to explicitly install the package, running   sudo dpkg -i bla.deb
(01:36:44 PM) dholbach: that's why you probably best check out https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases
(01:36:57 PM) dholbach: which explains how to have a separate, up-to-date development environment
(01:37:05 PM) dholbach: <slacker_nl> QUESTION: you've talked about development releases, what about backports, how does that process work, when does a package get backported?
(01:37:07 PM) dholbach: slacker_nl: good one
(01:37:40 PM) dholbach: slacker_nl: so we all work on karmic now.... it's going to be released on October 29th
(01:37:47 PM) dholbach: afterwards the karmic will be frozen
(01:37:51 PM) dholbach: no uploads to karmic anymore
(01:38:09 PM) dholbach: afterwards only uploads to karmic-security karmic-updates and karmic-backports are accepted
(01:38:44 PM) dholbach:  Effectively testing for regressions -- sbeattie  on Thursday will have more information on that
(01:38:54 PM) dholbach: https://wiki.ubuntu.com/SRU also explains it in more detail
(01:39:06 PM) dholbach: <openweek0_> QUESTION: where do i join if i wanna participate in gnome desktop env development?
(01:39:20 PM) dholbach: openweek0_: check out https://wiki.ubuntu.com/Teams for more information on various teams within Ubuntu
(01:39:52 PM) dholbach: <msp301> QUESTION: is that the same with LTS releases ? retricted updates etc ??
(01:40:06 PM) dholbach: msp301: no, what I just mentioned above concerns all releases, LTS or not
(01:40:25 PM) dholbach: LTS is just supported for longer than the "regular" 18 months, it's 3 years of support on the desktop and 5 on the server
(01:40:39 PM) dholbach: <c_korn> QUESTION: can I safely run "sudo rm -rf /var/cache/pbuilder/" to purge pbuilder ?
(01:40:41 PM) dholbach: c_korn: yes
(01:40:57 PM) dholbach: ok, now that we know how developers interact, one thing is VERY important
(01:41:06 PM) dholbach: always document changes you are about to make as good as you can
(01:41:32 PM) dholbach: we have people living in various parts on earth, speaking different languages and having different skill sets
(01:41:56 PM) dholbach: as we maintain all packages together as one big team it's important that other developers don't have to second guess what you might have meant
(01:42:16 PM) dholbach: also in 6 months time you probably don't want to second guess your own patches or documentation :)
(01:43:04 PM) dholbach: ok... speaking of patches and developers: we're not alone in the open source world
(01:43:24 PM) dholbach: we inherit a great deal of good stuff from the Debian project and other projects
(01:43:47 PM) dholbach: if we make changes we want to make sure to contribute them back to Debian, so let's take a quick look back at the hello example
(01:44:00 PM) dholbach: 2.4-1 is the version in karmic
(01:44:02 PM) dholbach: this means:
(01:44:25 PM) dholbach:  - 2.4 is the release that was done by the authors of hello on their homepage
(01:44:37 PM) dholbach:  - "-1" means that one revision of 2.4 was done in Debian and we inherited that
(01:44:45 PM) dholbach: debian/changelog has more information on what happened there
(01:44:55 PM) dholbach: if I was to do a change for Karmic, the new version string would be
(01:45:01 PM) dholbach:  2.4-1ubuntu1
(01:45:19 PM) dholbach: meaning: still 2.4 upstream release, one (inherited) debian revision, one Ubuntu change
(01:46:07 PM) dholbach: this also means that in the new Ubuntu release (karmic+1) we can't just copy (we call it 'sync') the package from debian, as we might overwrite the changes that I did in 2.4-1ubuntu1
(01:46:50 PM) dholbach: if there was a 2.5-1 in Debian, we'd need to very closely check if we can just overwrite my changes or if I need to merge the manually into the 2.5-1 Debian version (and thus get 2.5-1ubuntu1)
(01:47:15 PM) dholbach: to be able to sync as much as possible and share the same codebase all over it's necessary to send patches upstream
(01:47:37 PM) dholbach: On Wednesday we'll have a session called " Bug lifecycle, Best practices, Workflow, Tags, Upstream, Big picture" by jcastro and pedro_ who will talk about that some more
(01:48:00 PM) dholbach: <aacool> QUESTION: what do I run to test hello after the pbuilder build completes?
(01:48:23 PM) dholbach: aacool: you'd run    sudo dpkg -i /var/cache/pbuilder/result/hello*.deb    to install the resulting package
(01:48:25 PM) dholbach: and then run
(01:48:27 PM) dholbach:    hello
(01:48:33 PM) dholbach: in the command line :-)
(01:48:41 PM) dholbach: <penguin42> QUESTION: What happens with package numbering when ubuntu brings out a newer upstream version before debian does, then debian catches up?
(01:48:44 PM) dholbach: penguin42: nice one :)
(01:49:03 PM) dholbach: so let's say Debian is still on 2.4-1 and we discover there's a new release out by the hello upstream guys
(01:49:09 PM) dholbach: we'd call it 2.5-0ubuntu1
(01:49:33 PM) dholbach: to indicate: it's upstream 2.5, we didn't get a revision of it from Debian, but have the first revision of it in Ubuntu
(01:49:42 PM) dholbach: <[BIOS]Goo> QUESTION: Since Ubuntu is debian based, can i follow the same package building process for Debian as well?(using pbuild)
(01:49:50 PM) dholbach: [BIOS]Goo: essentially, yes
(01:50:07 PM) dholbach: https://wiki.ubuntu.com/UbuntuPackagingChanges explains what's different in the Ubuntu world
(01:50:19 PM) dholbach: <norax> QUESTION: What's the order? I mean hello.2.4-1 is before or after hello.2.10-1 ? If before, What goes after hello.2.10-1_ubuntu9? If after what happend if the upstream developer use a different notation?
(01:50:35 PM) dholbach: norax: first 2.4-1 then 2.10-1
(01:50:46 PM) dholbach: to be on the safe side, you can do this
(01:51:10 PM) dholbach: daniel@miyazaki:~$ dpkg --compare-versions 2.10-1 gt 2.4-1 && echo TRUE
(01:51:10 PM) dholbach: TRUE
(01:51:10 PM) dholbach: daniel@miyazaki:~$
(01:51:23 PM) dholbach: dpkg is always authoritative on package versions
(01:51:42 PM) dholbach: the command above checks if 2.10-1 is greater than 2.4-1 and print TRUE if it's true :)
(01:51:55 PM) dholbach: <soyrochus> QUESTION: Probably for last; how to clean up a system after using pbuilder. Not just apt-get remove, but more importantly removing all remants of local repositories, build remnants etc.
(01:52:10 PM) dholbach: soyrochus: just deinstall the packages that we installed, remove ~/.pbuilderrc and /var/cache/pbuilder
(01:52:14 PM) dholbach: that should get you there
(01:52:24 PM) dholbach: but more practically: use a virtual machine
(01:52:37 PM) dholbach: https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases
(01:52:47 PM) dholbach:  . o O { I didn't think that would be the most usef link today :-) }
(01:53:01 PM) dholbach: <playya> QUESTION: is it possibleto generate the debian/* file out of git TAGS, log,... and configure.ac?
(01:53:37 PM) dholbach: playya: yes, some people use distributed revision control for 1) the packaging itself and 2) packaging upstream snapshots from bzr/git/svn/cvs/etc
(01:53:49 PM) dholbach: <slacker_nl> QUESTION: regarding giving back: what is prefered, create a debian package and wait for Ubuntu to sync with debian or to create a ubuntu package directly? does debian sync with ubuntu?
(01:53:56 PM) dholbach: slacker_nl: that depends on the release schedule
(01:54:28 PM) dholbach: slacker_nl: if we're a week away from release and the fix is critical we might ask somebody from upstream for advice, but we won't block on them if we know that we need that fix
(01:54:44 PM) dholbach: https://wiki.ubuntu.com/Upstream has more info on our collaboration with upstreams
(01:55:16 PM) dholbach: ok... as last tips I'd like to give you:
(01:55:22 PM) dholbach:  https://wiki.ubuntu.com/MOTU/GettingStarted
(01:55:26 PM) dholbach: because it links to all the important stuff
(01:55:39 PM) dholbach:  https://wiki.ubuntu.com/Packaging/Training
(01:56:04 PM) dholbach: because of the session we'll have on thursday: general questions and answers about Ubuntu development, this place
(01:56:19 PM) dholbach: also please join us in #ubuntu-motu on irc.freenode.net
(01:56:25 PM) dholbach: and on the ubuntu-motu mailing list
(01:56:35 PM) dholbach: I really hope to see all of you during the great sessions we have this week
(01:56:45 PM) dholbach: and hope to see you all as Ubuntu contributors really really soon
(01:56:53 PM) dholbach: make me proud! :-)
(01:57:04 PM) huats: thanks dholbach !
(01:57:07 PM) dholbach: thanks everybody - have a great Ubuntu Developer Week!

MeetingLogs/devweek0909/GetStarted (last edited 2009-09-01 17:54:02 by kitlaan)