PackagingA
Ubuntu Open Week - Packaging 101 - Session 1 - Daniel Holbach - Tue, Apr 29, 2008
see also 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
MeetingLogs/openweekhardy/PackagingA (last edited 2008-08-06 17:00:17 by localhost)