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