Ubuntu Wiki

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!