Ubuntu Wiki

Ubuntu Open Week - Packaging 101 - Session 2 - Daniel Holbach - Wed, Oct 24, 2007

see also Tuesday session.

20:08 <+dholbach> alrightie, let's get going for round 2
20:08 <+dholbach> everybody doing alright?
20:09  * mbt nods
20:09 < peppych> yep
20:09 <+dholbach> rock on! :-)
20:09 <+dholbach> <harrisony> QUESTION: I just woke up and seems as if i missed the whole session, can i read the logs and ask you any questions later?
20:09 <+dholbach> harrisony: yes, somebody will post the link later on, I'm not sure where to find it right now :)
20:09 <+dholbach> <amarillion> QUESTION: I thought a good thing to fix a bug is attaching a debdiff to a bug report... but actually the debdiff output is just a list of files, not the files themselves
20:09 <+dholbach> amarillion: excellent question!
20:10 <+dholbach> amarillion: it depends if you run debdiff on two .deb files or on two .dsc files
20:10 <+dholbach> if you'd propose a new upstream version to get uploaded, you'd probably not attach the source diff
20:10 <+dholbach> but link to the source package you've uploaded somewhere
20:11 <+dholbach> you can use PPA for that (http://help.launchpad.net/PPAQuickStart) or REVU (http://wiki.ubuntu.com/REVU) and just link to the location of the .dsc file
20:11 <+dholbach> (so people can run   dget -x <dsc file>  to get the source and review it)
20:11 <+dholbach> <desertc> dholbach: Thanks for your talk.  Can you address the differences between the x86 and x86-64 packages?  Are all the packages available for both?  What are the policies of Ubuntu between these two architectures?
20:12 <+dholbach> desertc: yes, if you specify  Architecture: any  in debian/control, the source package will be built on all buildds, on all different architectures we use
20:12 <+dholbach> this is necessary for all packages that contain architecture dependent code
20:12 <+dholbach> you'd not need that for packages that contain only scripts (like python) or artwork, etc
20:13 <+dholbach> in their case you'd use    Architecture: all
20:13 <+dholbach> <effie_jayx> QUESTION: What was the bit that didn't cut it in the first session. I notice a new version of brasero being used for this one...
20:13 <+dholbach> effie_jayx: we used 0.5.90 which failed to build (because as seb128 pointed out, GtkToolTip was deprecated in GTK upstream), this has been fixed in 0.6.1
20:14 < effie_jayx> dholbach,  cool then...
20:14 < effie_jayx> :D
20:14 <+dholbach> any more questions?
20:14 <+dholbach> before we move on? :)
20:15 <+dholbach> alrightie
20:15 <+dholbach> in session two we'll produce a debdiff
20:16 <+dholbach> which will put you in the position to contribute patches that are ready for submission to review
20:16 <+dholbach> <mbt> QUESTION:  Is there an easy way to clean up build-deps when *not* using pbuilder?  Like the ones we installed earlier?
20:16 <+dholbach> mbt: you can use tools like deborphan for that
20:16 <+dholbach> ok, let's move on
20:17 <+dholbach> let's suppose we're all trying to fix an easy bug
20:17 <+dholbach> I'd like to point out that we have http://wiki.ubuntu.com/MOTU/TODO and http://wiki.ubuntu.com/MOTU/Bugs
20:17 <+dholbach> which list a bunch of easy bugs, things like the 'bitesize' tasks
20:18 <+dholbach> in this case we assume somebody complained that the package description of xicc contains 'colour' where it should say 'color' instead
20:18 <+dholbach> this is ridiculous and would be rejected, but let's do it as a simple excercise :)
20:18 <+dholbach> let's check if it's actually true:
20:18 <+dholbach>   apt-cache show xicc
20:19 <+dholbach> Description: set the ICC colour profile for an X display
20:19 <+dholbach>  This utility lets you set an ICC colour profile for an X display, so that
20:19 <+dholbach>  applications can use it to display colour calibrated images.  Applications have
20:19 <+dholbach>  to specifically look for this atom but several applications such as Gimp and
20:19 <+dholbach>  Eye Of Gnome already do.
20:19 <+dholbach> seems the person in the bug report is right
20:19 <+dholbach> let's get the source
20:19 <+dholbach>  dget -x http://people.ubuntu.com/~dholbach/motu/xicc_0.2-2.dsc
20:19 <+dholbach> again, it'll download the .orig.tar.gz the .diff.gz and the .dsc file and extract it automatically for us
20:20 <+dholbach>  cd xicc-0.2
20:20 <+dholbach> and check out debian/control
20:20 <+dholbach> in the binary packages stanza you'll see the package description
20:20 <+dholbach> we'll simply fix it, by running:
20:20 <+dholbach>  sed -i 's/colour/color/g' debian/control
20:20 <+dholbach> (you can do it manually too, if you like)
20:21 <+dholbach> again, we'll write a changelog entry to explain what we did and why
20:21 <+dholbach>  dch -i
20:21 <+dholbach> this time   0.2-2ubuntu1   would be the correct version number
20:21 <+dholbach> 0.2 to indicate the upstream version number
20:21 <+dholbach> -2 indicates the debian revision
20:21 <+dholbach> and ubuntu1 our change
20:22 <+dholbach> we'll change the upload target to hardy again
20:22 <+dholbach> (as it most likely wouldn't get accepted in gutsy-updates anyway)
20:22 <+dholbach> http://wiki.ubuntu.com/StableReleaseUpdates explains which kind of updates are accepted there
20:22 <+dholbach> as changelog entry, we'd write something like
20:23 <+dholbach>  "debian/control: changed all occurences of 'colour' to 'color'."
20:23 <+dholbach> it's important to point out the files you touched and why, it will make the work of other maintainers much easier
20:23 <+dholbach> especially in Ubuntu, where all packages are maintained by the whole team
20:23 <+dholbach> now run     debuild -S     to build the source package
20:24 <+dholbach> do you get the following line:
20:24 <+dholbach> dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
20:24 <+dholbach> debuild: fatal error at line 1247:
20:24 <+dholbach> ?
20:24 < mbt> Actually, I didn't.
20:24 < effie_jayx> I did
20:24 < peppych> line 1155 yes
20:25 < mbt> I got that as a warning, though.
20:25 <+dholbach> that's because of http://wiki.ubuntu.com/DebianMaintainerField
20:25 <+dholbach> our friends in the Debian project asked us to change the maintainer field for Ubuntu uploads
20:25 <+dholbach> so what we'll do is, change the Maintainer: string in debian/control
20:25 <+dholbach> we'll replace:
20:25 <+dholbach> Maintainer: Ross Burton <ross@debian.org>
20:26 <+dholbach> with
20:26 <+dholbach> XSBC-Original-Maintainer: Ross Burton <ross@debian.org>
20:26 <+dholbach> Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
20:26 <+dholbach> that way we preserve the original debian maintainer
20:26 <+dholbach> but set the maintainer string to the MOTU team
20:26 <+dholbach> which is the general contact for Universe and Multiverse packages
20:26 <+dholbach> we'll run    debuild -S   again
20:27 <+dholbach> (update-maintainer is a neat script in ubuntu-dev-tools which would actually have done the maintainer change for us)
20:28 <+dholbach> now you should have these files:
20:28 <+dholbach> xicc_0.2-2.diff.gz  xicc_0.2-2ubuntu1.diff.gz  xicc_0.2-2ubuntu1_source.build    xicc_0.2.orig.tar.gz
20:28 <+dholbach> xicc_0.2-2.dsc      xicc_0.2-2ubuntu1.dsc      xicc_0.2-2ubuntu1_source.changes
20:28 < effie_jayx> dholbach,  my key... ? debsign: gpg error occurred!  Aborting....
20:28 <+dholbach> effie_jayx: that's to be expected in this tutorial, that's fine
20:28 <+dholbach> if you follow https://help.ubuntu.com/community/GnuPrivacyGuardHowto you'll get around that hurdle too
20:29 <+dholbach> now if you run
20:29 <+dholbach>  debdiff xicc_0.2-2.dsc xicc_0.2-2ubuntu1.dsc
20:29 <+dholbach> it will show you the source changes we did
20:29 <+dholbach> can somebody pastebin their result somewhere?
20:29 <+dholbach> nobody?
20:30 < amarillion> just a sec :)
20:30 < mbt> 1 sec
20:30 < mbt> http://pastebin.com/m2f58fa1e
20:30 < peppych> http://pastebin.ubuntu.com/1301/
20:30 < effie_jayx> dholbach, http://pastebin.ubuntu.com/1302/
20:30 < amarillion> http://paste.ubuntu-nl.org/41984/
20:30 < amarillion> dang... too slow
20:31 <+dholbach> all look good!
20:31 <+dholbach> rock on!
20:31 <+dholbach> great work :-)
20:31 < effie_jayx> YEAH :D
20:31 <+dholbach>  debdiff xicc_0.2-2.dsc xicc_0.2-2ubuntu1.dsc > xicc_0.2-2ubuntu1.debdiff
20:31 < peppych> :)
20:31 <+dholbach> will give you the debdiff file you can attach to the bug report and you fixed the bug
20:31 <+dholbach> now you would just subscribe ubuntu-universe-sponsors to the bug and get a review
20:31 <+dholbach> first step to become a MOTU: DONE!
20:32 <+dholbach> in the real world, you'd add a   (LP: #1234567)   to the changelog entry
20:32 <+dholbach> (1234567 being the number of the bug)
20:32 <+dholbach> and it would get automatically closed, when the build daemon accepts your package
20:33 <+dholbach> <mbt> QUESTION:  How do you use the debdiff as someone that wants to apply it?  Just patch -p4 < file.debdiff?
20:33 <+dholbach> mbt: exactly, in most cases it's p1, but yeah, you just use patch
20:33 <+dholbach> any more questions?
20:33 <+dholbach> who could imagine walking the steps towards becoming a MOTU now? :-)
20:34  * mbt nods
20:34  * amarillion too
20:34 <+dholbach> great
20:34 <+dholbach> <effie_jayx> QUESTION: a patch would then be a debdiff between the old and new package?
20:34 < peppych> peppych nods too
20:34 <+dholbach> effie_jayx: yes, you'd run it on the .dsc files and attach it to the bug report
20:34 < MrPink> what exactly is this channel... will there really be "classes" here? Like someone telling or showing people how to do stuff? Os is this just a support channel like #ubuntu ?
20:34 <+dholbach> <amarillion> QUESTION: right now there are about 70 MOTU's. Is that too few? Debian has about 900 DD's I believe...
20:34 < mbt> MrPink: Please to go #ubuntu-classroom-chat
20:35 <+dholbach> amarillion: we're actively recruiting :-)
20:35 <+dholbach> amarillion: the MOTU team does a great job and works together with upstreams and Debian maintainers, but I'd like to encourage you all to join in
20:35 <+dholbach> the process is really straight-forward
20:35 <+dholbach> MrPink: http://wiki.ubuntu.com/UbuntuOpenWeek
20:36 <+dholbach> any more questions? about packaging? about Ubuntu development? about becoming a MOTU?
20:36 <+dholbach> (about me?) ;-)
20:37 <+dholbach> <pwnguin> QUESTION: if an MOTU objects to a debdiff, is there an authority to appeal to?
20:37 <+dholbach> pwnguin: you can always discuss packaging changes and problems you have on ubuntu-motu@lists.ubuntu.com
20:37 <+dholbach> pwnguin: we have quite a lot of people on the sponsoring team who do a very good job, so there will a be not just one pair of eyes on your debdiff
20:38 <+dholbach> <amarillion> QUESTION: I've seen mentioned that there are packages in debian that are not in ubuntu. So there is not a 1:1 correspondence, right? What could be reasons for packages not being in ubuntu?
20:38 < sistpoty> any other MOTU... in case there should real problems between a personal member arise, motu-council (or jono) would be the someone to contact
20:38 <+dholbach> sistpoty: for technical questions, I'd rather think ubuntu-motu@ or ubuntu-devel@
20:38 <+dholbach> but for social problems between maintainers, feel free to talk to me or the motu-council, right
20:38 <+dholbach> amarillion: in most cases this happens, when we turned the auto import of debian source packages off
20:38 < sistpoty> dholbach: definitely (was just an addition)
20:39  * dholbach hugs sistpoty
20:39 <+dholbach> (the MOTU team hugs a lot)
20:39  * sistpoty hugs dholbach
20:39 <+dholbach> :-)
20:39 < pwnguin> dholbach: in my case, its certainly not one i expect to have a lot of favor for overall, but i can imagine situations where one guy refuses a patch that many others would have accepted
20:39 <+dholbach> amarillion: we import source changes of debian during the first phase of the release cycle (if there are no ubuntu changes that could be overwritten)
20:39 <+dholbach> amarillion: in those cases we have to merge semi-manually
20:40 <+dholbach> amarillion: check out http://wiki.ubuntu.com/HardyReleaseSchedule for the current plan for hardy (and note the debian import freeze)
20:40 <+dholbach> pwnguin: right, that can happen: some sponsors will ask you to fix little bugs they see in your approach, some probably won't
20:40 <+dholbach> pwnguin: all of them are reasonable and you can talk to them
20:41 <+dholbach> <eolo999> QUESTION: What about refreshing docs about packaging, to be more linked to real practices?
20:41 <+dholbach> eolo999: I'm working on that: http://wiki.ubuntu.com/PackagingGuide will contain more hands-on examples like on http://wiki.ubuntu.com/MOTU/Recipes
20:41 <+dholbach> <mbt> QUESTION:  Where is more detailed information on using the build system to split packages apart into things like -doc and -dev and -dbg and the like?
20:41 <+dholbach> mbt: http://wiki.ubuntu.com/PackagingGuide should contain information on that
20:42 <+dholbach> mbt: it has a reference packages section too, in /Basic I believe
20:42 <+dholbach> <amarillion> dholbach, the package in question is batik. One time I requested in #ubuntu-motu that the batik library be packaged, and then somebody said that an old version was already in debian
20:42 <+dholbach> amarillion: it should be in hardy then, if it's not ask on ubuntu-motu@lists.ubuntu.com
20:42 <+dholbach> <willwill> QUESTION: I read from Wikipedia that it will be Ubuntu Grumpy Groundhog, unstable branch of ubuntu. How many Packages freshness that Grumpy have?
20:43 <+dholbach> willwill: Grumpy is a concept up until now and not implemented yet
20:43 <+dholbach> willwill: the plan is to import svn snapshots of upstream source and build them into packages
20:43 <+dholbach> about the frequency, I don't know
20:43 <+dholbach> <Riddell> QUESTION: what's the best way to build a package which has its debian/ directory kept in bzr?
20:43 <+dholbach> Riddell: excellent question
20:43 <+dholbach> some teams decide to not only use the archive as their main source repository but a version control system as well
20:44 <+dholbach> that way you have a team of contributors who don't need to be uploaders yet, but much broader
20:44 <+dholbach> bzr-builddeb is a really useful tool to achieve that
20:44 <+dholbach> you can pass --orig-dir=.. (or some such) to build it with an upstream tarball
20:44 <+dholbach> <amarillion> QUESTION: When running dh_make, one of the files generated is watch.ex. Supposedly to automatically track new releases. Can you explain a bit about them? Does that actually work well in practice?
20:45 <+dholbach> amarillion: it works very well
20:45 <+dholbach> amarillion: there's an example at http://wiki.ubuntu.com/MOTU/Recipes
20:45 <+dholbach> <mbt> QUESTION:  When putting packages together, can we do so for main as well as uni-/multi-verse?  e.g., GNU coreutils, which is VERY out of date, needs to be repackaged.  Is there any reason that any one of us could not do that?
20:45 <+dholbach> mbt: updates to tools like coreutils should be coordinated with people on ubuntu-devel@lists.ubuntu.com
20:46 <+dholbach> mbt: sometimes it's very easy to overlook implications of those changes
20:46 <+dholbach> mbt: is too huge a project to "just do it", but generally, yes: definitely, you can work on anything you like and propose it
20:46 < mbt> Very true, given the "centralness".  Which is why I was curious.  Thank you.  :)
20:46 <+dholbach> <pwnguin> QUESTION: which is more important to MOTU: fixing bugs users of Ubuntu experience, or cooperating with upstream? For example, gksudo is mildly broken, and an upstream pam module refuses a 3 line patch on grounds that its a hack
20:47 <+dholbach> pwnguin: the desktop team would deal with gksu, you should file a bug for it, attach the patch and ask for inclusion
20:47 < pwnguin> no no
20:47 <+dholbach> but yeah, both is important
20:47 < pwnguin> the patch is to the pam module, not gksudo
20:47 <+dholbach> ah ok
20:48 <+dholbach> in any case, you'd file a bug with the patch attached and subscribe the sponsors team
20:48 < pwnguin> it would be a massive gksudo patch, which is why its not fixed even though the desktop team knows, and as pursued it with gksudo upstream
20:48 <+dholbach> it's good to link to the upstream discussion too
20:48 <+dholbach> in some cases we decided to override upstream maintainers and do what was best in the situation to accomodate the needs of our users
20:48 <+dholbach> such decision are in some cases inevitable
20:48 <+dholbach> <aos101> Question: Do you need to know any particular programming languages to get involved with packaging, or is there lots you can do if you don't know C++ or whatever?
20:49 <+dholbach> aos101: more important than knowing programing languages is being able to learn, really motivated and being careful about changes you inflict on some million users
20:49 <+dholbach> along the way you'll learn about shell scripting and about Makefiles
20:50 <+dholbach> maybe some python bits, and in case you patch C or C++ source, maybe about those as well
20:50 <+dholbach> you'll learn step by step, but it's not a strict prerequisite to know about C++ or any other language when you start
20:50 <+dholbach> excellent questions
20:50 <+dholbach> any more of them? :)
20:51 <+dholbach> I'd like to reiterate: the cool thing about MOTU is that you can touch some 20000 packages and sky's the limit, you can fix user bugs, implement your own ideas, it's a great place to be involved in
20:51 <+dholbach> especially because you get in touch with so many different people
20:52 <+dholbach> and becoming a MOTU is really straight-forward
20:52 <+dholbach> <mbt> QUESTION:  How does one participate very early in the dev cycle for the next release?
20:52 <+dholbach>  (e.g., Hardy is certainly not going to be usable now, so how does one get started packaging for it and the like)?
20:52 <+dholbach> good question
20:52 <+dholbach> early in the release cycle we merge debian and ubuntu packages
20:53 <+dholbach> http://merges.ubuntu.com/universe.html for example shows the packages that need merging
20:53 < radmen> hi
20:53 < nalioth> radmen: class is goin on. please ask questions in #ubuntu-classroom-chat
20:53 <+dholbach> it's a great way to get involved, because you can try to actively reduce the delta between ubuntu and debian packages and feed those changes back to debian
20:53 <+dholbach> also in the beginning of the release cycle we take a look at NEW packages
20:53 < radmen> nalioth: sorry, will be quiet from now
20:53 <+dholbach> packages that are not in ubuntu or debian yet
20:54 <+dholbach> after Feature Freeze we mostly try to stabilize and fix as many bugs as we can
20:54 <+dholbach> including fixing FTBFS bugs
20:54 <+dholbach> making packages installable, etc
20:54 <+dholbach> <effie_jayx> QUESTION: I remember playing around with merges, What is MOM? and I know there is another like it but I can't remember the name. which do you use?
20:54 <+dholbach> effie_jayx: MOM is http://merges.ubuntu.com
20:55 <+dholbach> it look at debian and ubuntu packages and spits out a patch which in many cases is ready to be just applied
20:55 <+dholbach> DaD is a community contributed service that does the same but allows comments
20:56 <+dholbach> I mostly used MoM or merged by hand (in the case of desktop packages, we mostly merged and updated to a new upstream version in the same run)
20:56 <+dholbach> <mbt> QUESTION:  Let's say that I write a new piece of software, and want it to go into Ubuntu's universe right away, before the next release.  Is that feasible?  Or is new software required to have reasons or justifications for inclusion?
20:56 <+dholbach> mbt: if it's redistributable (good license) and is not the 10000th copy of something we already have, definitely bring it in! :)
20:56 <+dholbach> <willwill> QUESTION: What the advantage and disadvantage of checkinstall?
20:57 <+dholbach> willwill: checkinstall is a tool intended for users who don't want to bother getting into packaging themselves
20:57 <+dholbach> willwill: we developers don't use it
20:57 <+dholbach> it introduced a lot of problems in the past, I don't know if that's been fixed
20:58 <+dholbach> any more questions? :-)
20:58 <+dholbach> BRING IT ON everybody! I want to see as many of you becoming MOTUs in the hardy cycle as possible! :-)
20:59 < effie_jayx> dholbach,  thanks ... very enlighting this talk
20:59 < effie_jayx> :D
20:59 < DaveMorris> thanks
20:59 <+dholbach> <mbt> QUESTION:  Is there an end-all book for DEB packaging available somewhere that you are aware of?
20:59 < peppych> effie_jayx + 1
20:59 < peppych> thanks
20:59 <+dholbach> mbt: there's the debian policy and the debian maintainer guide linked from http://wiki.ubuntu.com/MOTU/Documentation
21:00 <+dholbach> all ubuntu packaging information is going to be merged into http://wiki.ubuntu.com/PackagingGuide
21:00 <+dholbach> I'm actively working on that
21:00 <+dholbach> <amarillion> QUESTION: is there an official policy for using either debhelper or cdbs?
21:00 <+dholbach> amarillion: no, not at all: I tend to use CDBS, because it makes my life easier
21:00 <+dholbach> but people have reasoned that it lacks documentation and avoid it, but it has proved to be very helpful to me
21:01 <+dholbach> (and avoided copy and pasting from other packages :))
21:01 <+dholbach> <sistpoty> QUESTION: what do you think is the coolest thing about getting involved with ubuntu?
21:01 <+dholbach> sistpoty: getting to learn people, learning something new every day, making users happy by fixing their bugs, having fun with a bunch of other people :-)
21:01 <+dholbach> <savvas> QUESTION: There are a lot of users practically complaining that when they submit a bug that the teams don't even look at it? What would you comment on that? Shouldn't there be a "just seen by someone from the staff"? Because as it is now, I think some if not many bugs are left behind
21:02 < sistpoty> and for me it's the amazing community (to add that)
21:02 <+dholbach> savvas: we're working on it and there'll be a session about the bug squad and dealing with bugs later this week
21:02 <+dholbach> it's proven hard to get back to all bugs, but we're doing better and better
21:02 <+dholbach> <mbt> QUESTION:  Is the path to becoming a core dev similar to the one to get to be a MOTU?
21:03 <+dholbach> mbt: yes, it consists of getting more experience and more experience
21:03 <+dholbach> the process is on http://wiki.ubuntu.com/UbuntuDevelopers too
21:03 <+dholbach> <Muzik-qa> QUESTION: so if i'm readin gthis right, I can go to  http://merges.ubuntu.com/universe.html and pick "Celestia" for example.  I do the process outlined here and bring it up to the debian version (CVS).  What is the 'base version' ?  How do you prevent all of us in here from all going and doing celestia (multiple effort)
21:03 < Muzik```> sorry... multiple effort should read redundant effort :)
21:03 <+dholbach> Muzik``: DaD tries to address that by using comments
21:03 <+dholbach> <LjL> QUESTION: follow up to willwill's - how would you see a tool that, while being targeted at end-users just like checkinstall, would strive to create packages that are as standards-abiding as possible? do you think such a tool would end up in better-quality packages (because more people can start very easily making packages) or in worse-quality ones (for exactly the same reason)?
21:04 <+dholbach> LjL: I don't think so - there's a lot to be considered when you do packaging
21:04 <+dholbach> LjL: in some cases it's very easy, but as soon as packages start to depend on other packages' functionality, you'll get into trouble
21:05 <+dholbach> I'm all for making the process easier, but there's no "do it all for me" tool yet
21:05 <+dholbach> ok everybody
21:05 <+dholbach> thanks for all your questions
21:05 <+dholbach> you all ROCK
21:05 < LjL> thank you
21:05 < mbt> Thank you for the session!
21:05 <+dholbach> and I hope to see you on the motu mailing lists and the irc channel soon
21:05 <+dholbach> have a great day