== Ubuntu Open Week - Packaging 101 - Session 1 - Daniel Holbach - Tue, Apr 29, 2008 ==
see also [[MeetingLogs/openweekhardy/PackagingB|Part 2]].

{{{
 LjL changed the topic of #ubuntu-classroom to: Ubuntu Open Week | Information and Logs: 

https://wiki.ubuntu.com/UbuntuOpenWeek | How to ask questions: https://wiki.ubuntu.com/UbuntuOpenWeek/Rules | Ask questions in #ubuntu-classroom-chat, prefaced with "QUESTION:" | See https://wiki.ubuntu.com/UbuntuOpenWeek/JoiningIn to filter out channel noise | Current session: Packaging 101 - Daniel Holbach

[16:00] <dholbach> Welcome everybody to the first of today's Ubuntu Open Week Sessions!

[16:00] <josc>  /ignore #ubuntu-classroom CRAP NOTICES SNOTES CTCPS JOINS PARTS QUITS KICKS MODES WALLOPS NICKS DCC DCCMSGS CLIENTNOTICES CLIENTCRAP CLIENTERRORS HILIGHTS

[16:00] <LjL> Please ask your questions in #ubuntu-classroom-chat (type /join #ubuntu-classroom-chat), and prefix them with "QUESTION:"

[16:00] <dholbach> Can we make it so that you either reply to questions for feedback or ask your own questions in #ubuntu-classroom-chat?

[16:01] <LjL> IRC commands start with / without any leading space

[16:01] <immesys> Please can we +m this room?

[16:01] <SanjayB> /ignore #ubuntu-classroom CRAP NOTICES SNOTES CTCPS JOINS PARTS QUITS KICKS MODES WALLOPS NICKS DCC 
DCCMSGS CLIENTNOTICES CLIENTCRAP CLIENTERRORS HILIGHTS

[16:01] <SanjayB> oops. sorry.

[16:01] <dholbach> We're going to go through a few tutorials together and I'll check back on how things are going every now and then - please speak up in #ubuntu-classroom-chat if that's OK :)

[16:02] <dholbach> So how are you all doing? How were yesterday's Ubuntu Open Week sessions?

[16:02] <dholbach> OK, let's get cracking

[16:03] <dholbach> in our first tutorial we're going to package a small piece of software - for that to work out we 
need to install a few tools first

[16:03] <dholbach> Which version of Ubuntu are you running?

[16:03] <dholbach> Anybody running Intrepid already? ;-)

[16:04] <dholbach> lots of Hardy users - excellent

[16:04] <dholbach> the tutorials should work on all the mentioned Ubuntu versions - if things should go wrong though, please speak up in #ubuntu-classroom-chat

[16:04] <dholbach> Please install the following packages:

[16:04] <dholbach>   sudo apt-get install devscripts build-essential wget fakeroot dh-make

[16:05] <dholbach> So we're going to package ed, the gnu line editor - first we'll download the tarball from the gnu ftp page

[16:06] <dholbach>  wget ftp://ftp.gnu.org/pub/gnu/ed/ed-0.9.tar.bz2

[16:06] <dholbach> The Debian and Ubuntu build-system expects us to upload .tar.gz tarballs afterwards, but as the upstream authors don't offer tar.gz, we will have to repack the tarball

[16:06] <dholbach>  tar xfj ed-0.9.tar.bz2

[16:06] <dholbach>  tar cfz ed_0.9.orig.tar.gz ed-0.9

[16:07] <dholbach> it's also important to note that we have to stick to this kind of nomenclature: ed_0.9.orig.tar.gz

[16:07] <dholbach> <upstream software name>_<upstream version>.orig.tar.gz

[16:08] <dholbach> and the 'orig' in the name is there for a reason: we don't introduce any changes, we keep the 
source as it is

[16:08] <dholbach> (there are a very very few exceptions to that - for example cases where we can't ship certain parts of the source code due to licensing problems, etc)

[16:09] <dholbach> did that work out for everybody up until now?

[16:09] <dholbach> excellent

[16:10] <dholbach> next we're going to use a utility called dh-make which will provide us with default values and default files for the packaging which will make our lives a lot easier

[16:10] <dholbach>  cd ed-0.9

[16:10] <dholbach>  dh_make -s -c gpl

[16:11] <dholbach> we told dh_make that we're packaging a single binary package (-s) and that the copyright is GPL

[16:11] <dholbach> So what does single binary package mean?

[16:13] <dholbach> As a package maintainer and developer you only work on the source of package, this involves the 
tarball (our .orig.tar.gz) plus some patches to make it build the debian/ubuntu way (we'll come to that in a bit)

[16:13] <dholbach> We upload this "source package" to the build daemon which will then generate the .deb files (binary 
packages) that we, our friends and our mothers will download and install

[16:14] <dholbach> from one source package we can generate multiple binary packages (at least one though)

[16:14] <dholbach> this is a simple example :)

[16:14] <dholbach> mono is a good example for how you can split up one source package into multiple binary packages:

[16:14] <dholbach>  apt-cache showsrc mono | grep Binary

[16:15] <dholbach> this lists some ~80 binary packages which are all built from one source package

[16:15] <dholbach> LjL: do we have questions already? :)

[16:15] <LjL> dholbach, i think the couple we had were answered already in the chat channel

[16:16] <LjL> [17:15:51] <czambran> QUESTIONS : Why would you break once source package into multiple binary packages?

[16:16] <dholbach> czambran: a very good question

[16:16] <dholbach> there are multiple reasons

[16:16] <dholbach> the most obvious one is: because some user groups have a different interest than others

[16:16] <dholbach> take a library package for example

[16:17] <dholbach> my mother will be only interested in the library runtime

[16:17] <dholbach> I might be interested in developing with the library, so I might need all the header files in 
/usr/include

[16:17] <dholbach> the same goes for huge directories of documentation, etc

[16:17] <dholbach> it saves space on the disk (and CDs!), bandwidth, etc

[16:17] <dholbach> another question I saw was this one:

[16:18] <dholbach> <RoAkSoAx> QUESTION: How to change e-mail showed after executing  dh_make -s -c gpl

[16:18] <dholbach> RoAkSoAx: thanks a lot for prodding me about it - it's something I forgot and should have said 
earlier

[16:18] <dholbach> dh_make (and other packaging tools) can use an environment variable we should probably set before 
to make things easier

[16:19] <dholbach> please edit your   ~/.bashrc   file (or .zshrc if you use zsh) and add something along the lines 
of:

[16:19] <dholbach>  export DEBFULLNAME='Daniel Holbach'

[16:19] <dholbach>  export DEBEMAIL='daniel.holbach@ubuntu.com'

[16:19] <dholbach> then save it and please run

[16:20] <dholbach>  source .bashrc        (or restart your terminal)

[16:20] <LjL> [17:17:39] <Syntux> QUESTION: What if the source included the application dependent libraries; do we have to include them in the package ?

[16:21] <dholbach> Syntux: good question - in that case it's definitely worth to tallk to the upstream developers and ask them to ship just their own source in their tarballs

[16:21] <dholbach> unfortunately some (but not too many) upstream authors think that it would make their users live easier if they shipped all kinds of source code in their tarballs

[16:22] <dholbach> the ubuntu archive admins can get a bit shirty with you because of that for a simple reason: duplicated code

[16:22] <dholbach> we really like to have all code just in one place, so if there's a critical fix (like a security 
problem) we only need to fix it in one place

[16:22] <LjL> perhaps it's also worth pointing this one out although it was answered, as there could be some confusion due to most packages having source that needs to be compiled: <phil_> QUESTION:  What about programs that don't need compiling, like written python?

[16:22] <dholbach> did everybody update their  ~/.bashrc ?

[16:24] <dholbach> phil_: we use one build process for all kinds of packages, so no matter if it's C, Mono, Java, Python, Perl or just a bunch of .png files you want to ship to your users: all use the same build process and all install the files that are shipped to the user during that build process

[16:24] <dholbach> after the  ~/.bashrc  change, please run:

[16:24] <dholbach>  rm -r debian; dh_make -s -c gpl

[16:25] <dholbach> <memnon> QUESTION: AFAIK, Debian and Ubuntu are not fully compatible anymore. Can I make sure a built package works on both?

[16:25] <dholbach> memnon: you can have a debian chroot where you can test the build, if it works in debian (https://wiki.ubuntu.com/DebootstrapChroot) or use pbuilder (https://wiki.ubuntu.com/PbuilderHowto)

[16:26] <dholbach> alright.... let's crack on

[16:26] <dholbach> we just generated the defaults again, after we set DEBFULLNAME and DEBEMAIL - things should look a bit better now :)

[16:26] <dholbach> let's see what dh_make generated for us:

[16:26] <dholbach>  cd debian/

[16:27] <dholbach>  ls

[16:27] <dholbach> you can see a lot of files, lots of them have a very special purpose only and it's just too much to cover in this session

[16:27] <dholbach> http://wiki.ubuntu.com/PackagingGuide has a lot of useful information and lots of links to docs you will need to make use of the advanced features

[16:28] <dholbach> our package is going to be very simple and very straightforward, that's why we're going to remove a lot of example files now

[16:28] <dholbach>  rm *.ex *.EX dirs docs README.Debian

[16:28] <dholbach> changelog  compat  control  copyright  info  rules          should be it now

[16:29] <dholbach> let's edit the changelog first

[16:29] <dholbach> every change in Ubuntu and Debian has to be properly documented

[16:29] <dholbach> if you want to figure out why something broke or behaves differently you usually check the 
changelog first

[16:30] <dholbach> and because people are going to use your package and you collaborate with a lot of people on it you do them a favor and let them know very explicitly what you do :)

[16:30] <dholbach> the first changelog entry is not very exciting though: something like "Initial release" should be enough

[16:30] <dholbach> it might also be worth pointing out that we re-packed the tarball (without changes)

[16:31] <dholbach> <Zelut> QUESTION: Does this chagelog just contain package-related changes or source code related changes?

[16:31] <dholbach> Zelut: good question

[16:31] <dholbach> Zelut: some maintainers like to point out major changes that a new upstream version introduced, but there's no strict must
[16:32] <dholbach> if you'Re on hardy, check out:

[16:32] <dholbach>  zless /usr/share/doc/gedit/changelog.Debian.gz

[16:32] <dholbach> you can see that seb128 explained what the new upstream version gained us

[16:32] <dholbach> but let's crack on - let's make the changelog ubuntu compliant :)

[16:32] <dholbach> our changelog.... :)

[16:33] <dholbach> first we'll change the version number to 0.9-0ubuntu1

[16:33] <dholbach> the version number has the following format:

[16:33] <dholbach>  - packages that have no ubuntu changes:    <upstream version>-<debian revision>

[16:34] <dholbach>  - packages that HAVE   ubuntu changes:    <upstream version>-<debian revision>ubuntu<ubuntu 
revision>

[16:34] <dholbach> as our own package never was in debian, <debian revision> will be "0" in our case

[16:34] <dholbach> hence 0.9-0ubuntu1

[16:35] <dholbach> we'll also change 'unstable' (the debian default) to 'intrepid'

[16:35] <dholbach> why?

[16:35] <dholbach> because intrepid is the current development release and we can only upload to the current 
development release

[16:35] <dholbach> (hardy-updates, hardy-security, hardy-backports, etc are exceptions)

[16:35] <dholbach> we'll not change the urgency as it has no effect in the ubuntu build system

[16:36] <dholbach> the "changelog part" of the entry should be something like

[16:36] <dholbach>   * Initial release.

[16:36] <dholbach>   * Re-packed from .tar.bz2 (no changes).

[16:37] <dholbach> can you post your changelog entry to http://paste.ubuntu.com/ and post the link in 
#ubuntu-classroom-chat if you made it?

[16:38] <dholbach> mfm: good work

[16:38] <dholbach> lmontrie: that looks good

[16:39] <dholbach> <Syntux> QUESTION: Do we have to stick to certain text format in changelog? tabs/spaces ?

[16:39] <dholbach> Syntux: if you use an editor like 'vi' it will let you know about syntax problems in 
debian/changelog - also the packaging tools we're going to use to build the packages will complain

[16:39] <dholbach> <RoAkSoAx> QUESTION: when packaging or merging for the current development release... in this case, 
should be do it using Intrepid or we can do it on hardy. How, using a pbuilder

[16:40] <dholbach> RoAkSoAx: https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases is the answer

[16:40] <dholbach> there are lots of ways in which you can use the development release - it's important that you're 
able to

[16:40] <dholbach>  - test build your package

[16:40] <dholbach>  - test your package

[16:40] <dholbach> in the release that you're going to upload to

[16:41] <LjL> <immesys> QUESTION: Should we package restricted content such as graphics drivers too? Or should we 
stick to Debian packages?

[16:41] <dholbach> Syntux: yours looks good too, although I'd personally add a newline below the last bullet point 
(but yours is OK)

[16:42] <dholbach> immesys: there are restrictions on what we're allowed to ship in Ubuntu - it has to be 
redistributable - there's a wiki page which explains that but I don't have the URL handy right now - can somebody give 
it to immesys?

[16:42] <dholbach> so we have the changelog sorted out, let's crack on

[16:44] <dholbach> we'll skip the files compat (defines debhelper compatibility level - check out debhelper(7) for 
more info) and info (info page for the ed package) as they should be OK as they are

[16:44] <LjL> dholbach: it might be http://www.ubuntu.com/community/ubuntustory/licensing that you wanted to point 
immesys to

[16:44] <dholbach> LjL: thanks - that looks like a good start

[16:45] <dholbach> a lot of important information is available from http://wiki.ubuntu.com/UbuntuDevelopment too (how 
the archive works, ubuntu policies, etc)

[16:45] <dholbach> let's edit the  control  file now

[16:45] <dholbach> it carries the important information about binary and source packages I talked about earlier

[16:46] <dholbach> it consists of a source stanza (always the first in the file) and one or multiple binary stanzas

[16:46] <dholbach> we'll only make minimal changes to it right now

[16:47] <dholbach>  Section: editors              should be fine

[16:47] <dholbach> one important field in the source section is "Build-Depends"

[16:48] <LjL> <Zelut> QUESTION: Is there a list of possible 'section's that can be referred to?

[16:48] <dholbach> it means: installing these packages into a minimal system will suffice to make it built

[16:48] <dholbach> Zelut: http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections

[16:50] <dholbach> what happens if we upload our source package to a build machine is: use a fresh minimal 
environment, then install the build-depends

[16:51] <dholbach> in our case we'll stick to the defaults as ed doesn't need a lot of build-dependencies (just 
libc6-dev, which is always installed by means of 'build-essential')

[16:51] <dholbach> if you package a C or C++ piece of software it's usually worth reading configure.ac or configure.in 
to find out what the build-dependencies are

[16:51] <dholbach> also the README file is a good source for that

[16:52] <dholbach> the pbuilder tool I referred to earlier does the same as the build machines in the data centre: it 
uses a fresh minimal environment, then installs the build-depends, then build your package

[16:52] <dholbach> http://wiki.ubuntu.com/PbuilderHowto if you want to try it out

[16:52] <dholbach> <mfm> QUESTION: So do I have to add libc6-dev to my Build-Depends?

[16:53] <dholbach> mfm: no, build-essential is always installed and get libc6-dev for you

[16:53] <dholbach> other than that the source stanza is looking quite good now

[16:54] <dholbach> the second stanza is about the binary package we install

[16:54] <dholbach> of couse we want a nice description, so adept and synaptic users know what "ed" is all about

[16:54] <dholbach> so let's get the description from the README file:

[16:55] <dholbach> Description: standard Unix line editor

[16:55] <dholbach>  GNU ed is an 8-bit clean, more or less POSIX-compliant implementation

[16:55] <dholbach>  of the standard Unix line editor. These days, full-screen editors have

[16:55] <dholbach>  rendered `ed' mostly of historical interest. Nonetheless, it appeals

[16:55] <dholbach>  to a handful of aging programmers who still believe that "Small is

[16:55] <dholbach>  Beautiful".

[16:55] <dholbach> is what I put in there

[16:55] <Mez> <lmontrie> QUESTION: What does the 'Standards-Version' field means ?

[16:56] <dholbach> the first line is the "short description", the subsequent lines (all indented by one space) are the 
long description

[16:56] <dholbach> lmontrie: good question - I omitted that

[16:56] <dholbach> Standards-Version refers to the version of the debian policy your package complies with

[16:56] <dholbach> if you type:

[16:56] <dholbach>  apt-cache show debian-policy | grep ^Version

[16:56] <dholbach> if will show which version of the debian policy is available on your system

[16:57] <dholbach> it's an important document that will in most of the cases have the answer to your question :)

[16:57] <dholbach>     Architecture: any     is important too

[16:57] <dholbach> it means that our package will be built on any of the architectures in the data centre

[16:58] <dholbach> which means: i386, amd64, powerpc, sparc, hppa, lpia, ia64, etc

[16:58] <dholbach> we compile C code in this package which is going to be architecture specific

[16:58] <dholbach> if you just happen to ship some perl scripts, you can change the field to

[16:58] <dholbach>     Architecture: all

[16:59] <dholbach>    Depends: ${shlibs:Depends}, ${misc:Depends}

[16:59] <dholbach> is the most daunting looking line - what is it about?

[16:59] <dholbach> ${shlibs:Depends} is a variable that will be substituted after the build

[17:00] <dholbach> it will contain all the library packages that contain libraries that the binaries in the ed package 
are linked to

[17:00] <dholbach> does that make sense? :)

[17:01] <Mez> Mixed opinion it seems dholbach.. An example maybe?

[17:02] <dholbach> OK, I just installed the existing ed package of the archive, if I run ldd on the /bin/ed binary, it 
gives me:

[17:02] <dholbach> daniel@lovegood:~/1$ ldd /bin/ed

[17:02] <dholbach> 	linux-gate.so.1 =>  (0xb7f9e000)

[17:02] <dholbach> 	libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e3e000)

[17:02] <dholbach> 	/lib/ld-linux.so.2 (0xb7f9f000)

[17:02] <dholbach> daniel@lovegood:~/1$

[17:03] <dholbach> what it spits out is the libraries /bin/ed is linked against

[17:03] <dholbach> the build process will translate library file names into library packages and note them in the 
Depends: field afterwards

[17:04] <dholbach> never specify explicit library dependencies by hand

[17:04] <dholbach> this process is really elegant

[17:05] <dholbach> ${misc:Depends} is another substitution variable which is used in special cases like gnome (it will 
for example contain gconf if one of the packaging tools identifies gconf schemas are installed, etc)(

[17:05] <dholbach> ${misc:Depends} is empty most of the time

[17:05] <dholbach> debian/control should be all set now

[17:06] <dholbach> can you post your debian/control file to http://pastebin.com/ (or any other pastebin site that 
works) and post the link  in  #ubuntu-classroom-questions ?

[17:08] <dholbach> MattJ: looks good, PartyBoi2: could do with a bit of editing in the description - other than that 
good

[17:08] <Mez> dholbach, I think you mean #ubuntu-classroom-chat ?

[17:08] <dholbach> Zelut: good

[17:08] <dholbach> Mez: yes, sorry

[17:08] <dholbach> lmontrie: great

[17:09] <dholbach> kef_kf: looking good

[17:09] <dholbach> Syntux: one newline too much in the description - you'd at least need a " ." to split the text up a 
bit

[17:10] <dholbach> mfm: good

[17:10] <dholbach> czambran: make it one space instead of a tab - other than that good

[17:10] <dholbach> wow.... good work everybody :)

[17:11] <dholbach> the next file we're going to look at is really really important

[17:11] <dholbach> copyright

[17:11] <dholbach> it contains information about the authors, the copyright holder and license of each file that 
you're shipping

[17:12] <dholbach> the archive admins will make sure that debian/copyright is in tip-top state and that you've not 
left anything out and that all source is perfectly redistributable

[17:12] <dholbach> the more careful you are in making sure that it's alright, the happier they'll be with you - and 
you want them happy :)

[17:13] <dholbach> can you open another terminal, cd into the ed-0.9 directory and run:

[17:13] <dholbach>   find . -name '*.c' | xargs head | less

[17:14] <dholbach> this will display you the top lines of each .c file in the source

[17:14] <dholbach> please note that that's not enough to ensure that everything you ship is alright, but just 
illustrates what you look at and what you look for

[17:15] <dholbach> for now we'll just refer to:

[17:15] <dholbach>     Copyright (C) 1993, 1994 Andrew Moore, Talke Studio

[17:15] <dholbach>     Copyright (C) 2006, 2007, 2008 Antonio Diaz Diaz.

[17:15] <dholbach> as the copyright holders

[17:15] <dholbach> also please see the AUTHORS file

[17:15] <dholbach> we'll copy the authors from there into the   Upstream authors:   section in debian/copyright

[17:16] <dholbach> also you need to point out where you obtained the tarball from - pointing to    
ftp://ftp.gnu.org/pub/gnu/ed/     should be good enough

[17:17] <dholbach> https://wiki.ubuntu.com/PackagingGuide/Howtos/DebianCopyright explains a bit more about it

[17:18] <dholbach> next let's take a quick look at debian/rules

[17:19] <dholbach> it's a Makefile which contains standard targets the debian/ubuntu build process expects

[17:21] <dholbach> it usually contains: build, binary, binary-arch, binary-indep, clean - if it confuses you right 
now, that's OK

[17:22] <dholbach> we'll leave debian/rules as it is for our example and I usually recommend to work on existing 
packages and modify existing bits to get a better feeling for the build process and which bits are called when

[17:22] <dholbach> what we'll do now is generate the source package from the changes we just did

[17:22] <dholbach> please run

[17:22] <dholbach>   debuild -S

[17:23] <dholbach> and see:

[17:23] <dholbach>  ls ../..

[17:23] <dholbach> you should have a .diff.gz and a .dsc file in addition to the .orig.tar.gz we created initially

[17:24] <dholbach> <mfm> QUESTION: run dbuild from debian or ed-0.9?

[17:24] <dholbach> mfm: both should work

[17:25] <dholbach> .orig.tar.gz is the unmodified tarball

[17:25] <dholbach> .diff.gz is the compressed changes we had to make to make it build the ubuntu/debian way :)

[17:26] <dholbach> some of you got a GPG warning

[17:26] <dholbach> that does not indicate a failed build, but that you might need to set up GPG properly

[17:26] <dholbach> I didn't make this part of this tutorial to safe us a bit of time: 
https://help.ubuntu.com/community/GnuPrivacyGuardHowto is a very good guide to get you up and running

[17:27] <dholbach> the .dsc file is a description file that contains md5sums of .orig.tar.gz, the .diff.gz and the 
like - together they are what we call a source package

[17:28] <dholbach> ok... now that we have our source package all set - let's get us a binary package

[17:28] <dholbach> cd back into the ed-0.9 tree

[17:28] <dholbach> and run       debuild -us -uc            (this will run the build and omit the final step of 
signing the package)

[17:28] <dholbach> <Zelut> QUESTION: Is there a way to export GPG settings in a similar way we exported EMAIL and 
NAME?

[17:29] <dholbach> Zelut: the packaging tools will make use of the gpg key that has the key id that matches your 
DEBEMAIL

[17:29] <dholbach> at the end of our build lintian might emit a few warnings and errors: this is kind of things you 
will need to work out if you work on a real package and not a silly example as we do over here :)

[17:30] <dholbach> for now we can ignore them

[17:30] <dholbach> a    ls ../*.deb    should mention a package we just build

[17:30] <dholbach>  less ../ed_0.9-0ubuntu1_*.deb    should give you information about the package we just built

[17:30] <dholbach>  - contents

[17:31] <dholbach>  - package description

[17:31] <dholbach>  - version

[17:31] <dholbach> and note:

[17:31] <dholbach>  Depends: libc6 (>= 2.4)

[17:31] <dholbach> did that work out for everybody?

[17:33] <dholbach> excellent - a whole lot of succesfully built packages - congratulations everybody  :)

[17:33] <dholbach> do we have some questions? :)

[17:33] <dholbach> <mfm> QUESTION: It shows "libc6 (>= 2.6-1)" for me - depends on the Release which it has been buid?

[17:34] <dholbach> mfm: yes, that depends on which release you built the package

[17:34] <dholbach> <Syntux> Okie, we got the package, whats the root pass to upload it :p

[17:34] <dholbach> Syntux: you need to have signed it with a gpg key that is registered on Launchpad for a user that 
is in the ~ubuntu-dev team

[17:35] <dholbach> the rest is here:   https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Uploading

[17:35] <dholbach> that's why following   https://help.ubuntu.com/community/GnuPrivacyGuardHowto   and reading it 
thoroughly is important :)

[17:36] <dholbach> other than that I recommend #ubuntu-motu on irc.freenode.net as a means of getting in touch with 
developers and asking questions regarding packages

[17:36] <dholbach> and ubuntu-motu-mentors@lists.ubuntu.com

[17:37] <dholbach> http://wiki.ubuntu.com/MOTU/GettingStarted is a good guide and links to all the important 
information

[17:37] <dholbach> <Zelut> QUESTION: If we've built a package that we want reviewed do we just annoy -motu or are 
there mentors we can ask?

[17:37] <dholbach> Zelut: https://wiki.ubuntu.com/MOTU/Packages/REVU explains how you can upload a package for review

[17:38] <dholbach> if you have specific questions you can always ask in #ubuntu-motu

[17:38] <dholbach> any more questions?

[17:39] <dholbach> who enjoyed their first ride through packaging? who wants more of it? :)

[17:40] <dholbach> https://wiki.ubuntu.com/PackagingGuide/HandsOn has some more tutorials you can go through on your 
own later

[17:40] <dholbach> <maco> QUESTION: this is PPA-related.  ive tried to upload the same .orig.gz before but with a 
different .diff.gz and a lower version number to upload for a different version (wanted to compile for gutsy and 
hardy), but it said the orig didn't match. What'd i do wrong there?

[17:40] <dholbach> for everybody who's not familiar with PPAs: please see http://help.launchpad.net/PPAQuickStart

[17:40] <dholbach> it's basically a build service for testing and sharing packages

[17:41] <dholbach> maco: a lower version number does not work out if it accepted a higher version number before - but 
that should have been explicit in the rejection mail

[17:42] <dholbach> best to ask in #launchpad or ask in the session later on at 19:00 UTC

[17:42] <dholbach> <Syntux> QUESTION: When a MOTU wannabe should apply to become part of the official team? do s/he 
have to be seriously fluent in packaging or there are another way of defining the expertise level.

[17:42] <dholbach> excellent question

[17:42] <dholbach> http://wiki.ubuntu.com/UbuntuDevelopers explains more about the actual process of applying

[17:42] <dholbach> so how does one become a MOTU?

[17:43] <dholbach> basically it boils down to: contribute, get good quality packages and patches uploaded by people 
who are in the ubuntu-dev team already (http://wiki.ubuntu.com/SponsorshipProcess)

[17:43] <dholbach> until they tell you: "hey you're doing great - why don't you apply for MOTU?"

[17:44] <dholbach> then you apply with a brief explanation of what you've done, what you want to do and your sponsors' 
feedback at the MOTU Council

[17:44] <dholbach> I generally recommend to work on existing packages and fix a few 'bitesize' bugs before starting to 
package random software

[17:44] <dholbach> it's better to start off small and get a feeling for the build process, for how packages work and 
so on

[17:45] <dholbach> https://wiki.ubuntu.com/MOTU/TODO should list a lot of tasks you can get cracking on

[17:45] <dholbach> <Zelut> QUESTION: Do you have an example copyright for ed you can show us?  We kinda breezed 
through that one quickly.

[17:45] <dholbach> Zelut: no, but I'll post one later

[17:45] <dholbach> <Syntux> QUESTION: What's the best way to find unpackaged applications that people need especially 
with the large repository of debian and Ubuntu it's really hard to find the kick start package.

[17:46] <dholbach> Syntux: as I said above: I *REALLY* recommend working on existing packages - in Ubuntu we maintain 
all the packages as a team

[17:46] <dholbach> of couse some people have more expertise with certain packages than others, but there's no "big 
maintainer lock" which prevents others from working on the same package or as a maintenance team

[17:47] <dholbach> so I'd rather start off with picking a bug, and getting a small piece of the puzzle to work again

[17:47] <dholbach> you can even do it as your http://wiki.ubuntu.com/5-A-Day :)

[17:48] <dholbach> but if you really want to package a piece of software that somebody else has good use for, try: 
https://bugs.launchpad.net/ubuntu/+bugs?field.tag=needs-packaging

[17:48] <dholbach> for that it's important to point out a few things:

[17:49] <dholbach>  - putting your name in the maintainer field means: you're going to take good care of it (read bug 
reports, talk to the upstream developers, take care of making it work as good as you can etc)

[17:49] <dholbach>  - that works best if you take care of a piece of software that you yourself have a good use for

[17:49] <dholbach> >RoAkSoAx> QUESTION: regarding to copyright question of Zelut , would it be like this?: 
http://pastebin.com/m6a7116d4

[17:50] <dholbach> the upper part looks quite OK already

[17:50] <dholbach> what's missing is the GPL3 text

[17:50] <dholbach> if you check out the top lines of the .c files you will notice that it mentions GPL3, not GPL2

[17:51] <dholbach> this makes a big difference and will be something the archive admins will complain about

[17:51] <dholbach> also we would have to make sure that

[17:51] <dholbach> #

[17:51] <dholbach>     Copyright (C) 1993, 1994 Andrew Moore, Talke Studio

[17:51] <dholbach> #

[17:51] <dholbach>     Copyright (C) 2006, 2007, 2008 Antonio Diaz Diaz.

[17:51] <dholbach> are the only copyright holders

[17:51] <dholbach> it'd require some more love

[17:51] <dholbach> <Zelut> QUESTION: If we write a peice of software that we want to submit for inclusion is it still 
the same REVU process?

[17:52] <dholbach> Zelut: yes, you will submit your new package to REVU, will let it get 2 ACKs, then it can be 
uploaded to the archive

[17:52] <dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages has more to say about that

[17:53] <dholbach> you'll get extra points for having a "good contact to the upstream author" though :)

[17:53] <dholbach> more questions?

[17:53] <dholbach> <Syntux> So it seems a MOTU works as a middle man between the upstream developers and Ubuntu 
repository, the scenario should be something like, picking a package (new or existing), follow up on bugs, patches, 
releases and put the result in a package

[17:53] <dholbach> Syntux: exactly

[17:54] <dholbach> and that's what makes it fun - you deal with a lot of people: your users, the debian maintainers, 
maintainers of other distributions, upstream developers etc

[17:54] <dholbach> and by making things work you'll make a lot of people very happy :)

[17:55] <dholbach> So who of you can we expect in #ubuntu-motu for making intrepid ROCK?

[17:56] <dholbach> excelltn :)

[17:56] <dholbach> <maco> QUESTION: how does making a debdiff differ from making a normal source deb?

[17:56] <dholbach> maco: if you post a source package for REVU you upload the full .orig.tar.gz .diff.gz and .dsc 
files somewhere

[17:57] <dholbach> in the case of a debdiff it's just a diff file with the changes you did in a fix upload for example

[17:57] <dholbach> Check out https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff for an example

[17:57] <dholbach> another important part of developing Ubuntu:

[17:57] <dholbach> Hugging!

[17:58]  * dholbach hugs y'all :)

[17:58] <dholbach> You all ROCK and I hope you had big fun in the session - because I did

[17:58] <dholbach> The next session is "Ubuntu Mobile Edition - An introduction and Q+A - Adilson Oliveira"

[17:59] <dholbach> please do send me a mail on how your doing regarding packaging and doing development

[17:59] <dholbach> you all rock!
}}}



==== Page B links to this page ====