Dev Week -- How to fix small bugs in Ubuntu -- warp10 -- Thu, 3rd Feb, 2012

   1 [21:00] <warp10> Hi all!
   2 [21:00] <warp10> Who's here to learn how to hunt down bugs? Raise your hands in #ubuntu-classroom-chat, guys!
   3 [21:01] <warp10> Ok, great!
   4 [21:01] <warp10> Introductions first: I am Andrea Colangelo, Ubuntu Developer since 2008, with a particular focus on QA, and proudly member of a few teams of the rocking Italian Loco Team too.
   5 [21:02] <warp10> In the next ~30 minutes we will have a glance at how to fix small bugs in Ubuntu.
   6 [21:02] <warp10> If you followed the previous sessions, you already know how to setup your development box and the tools we use everyday, right?
   7 [21:03] <warp10> In this session we will pick a few interesting bugs, already fixed and closed, and we will see how they have been solved.
   8 [21:03] <warp10> This will cover both technical and "social" aspects. The latter are extremely important, since they impact the way you relate to you fellow ubuntu developers and upstreams.
   9 [21:03] <warp10> One of our very special upstreams is Debian, and very often bugfixing is worth being done there rather than here in Ubuntu.
  10 [21:04] <warp10> If you followed Laney and tumbleweed yesterday, they held great sessions about working {in,with} debian. I recommend reading them if you didn't already
  11 [21:04] <warp10> So, let's get started!
  12 [21:04] <warp10> Our first bug will be:
  13 [21:05] <warp10> Although it's quite old right now, it's a nice example of the good old debdiff-way of doing things.
  14 [21:05] <warp10> Looking at archive rebuild test result, I noticed abiword did FTBFS. Do you know what does this acronym means?
  15 [21:06] <warp10> It stands for "Fail To Build From Source". It's pretty common in Debian/Ubuntu Development: it just means that a source package doesn't compile correctly and doesn't build a binary package. A pretty bad situation, as you can imagine.
  16 [21:07] <warp10> To investigate the bug I carefully checked the build log, it is still available here:
  17 [21:07] <warp10> As you see, it crashes with a sad error: "E: Package libgoffice-0-5-dev has no installation candidate". Nevertheless, the builder itself gives us an hint, saying that libgoffice-0-6-dev replaces it.
  18 [21:07] <warp10> What happened is that a new release of libgoffice overseded the older package. A pretty common situation who typically leads to a bad, but easily fixable, FTBFS.
  19 [21:08] <warp10> Patch is really simple. I downloaded the source package with `apt-get source abiword`. This command grabs the three files of the source package from archive, unpack the original tarball and applies the diff file containing the debian/ directory. I guess you already had a chance to learn about this in a previous session.
  20 [21:09] <warp10> Although we are moving towards using bzr in the Ubuntu Distributed Development way-of-life, knowing the old good methods (who are currently used in Debian!) is still a good thing to know, so questions are welcomed if something is unclear.
  21 [21:09] <warp10> The file containing the dependencies needed to build the package is debian/control, so I modified the build-dep name there.
  22 [21:09] <warp10> I also changed the changelog to bump the package version number and drop a line about what I did.
  23 [21:10] <warp10> !Q
  24 [21:11] <ClassBot> kanliot asked: I don't know the location of the debian director, or where the apt-get source files get put
  25 [21:11] <warp10> kanliot: debian/directory is in the root of the source tree. And the source package is taken from the archive itself
  26 [21:11] <warp10> Then, I simply rebuilt the source package with debuild -S, then compared the two source packages (the original one and the fixed one) with debdiff to extract the patch I attached to the bug report:
  27 [21:12] <warp10> Do you know debdiff? It's a sort of wrapper around the diff utility specifically targeted to debian packages. It produces patches that you can apply to a source tree with patch. Please check `man debdiff` for more info.
  28 [21:12] <warp10> At the time I fixed this bug I wasn't a MOTU already, so I created the debdiff, attached it to the bug report, and a couple days later a sponsor uploaded it into archive. Of course, I build-tested my fixed package with pbuilder before submitting the debdiff: you absolutely don't want to propose patch without a thorough testing, do you?
  29 [21:12] <warp10> Debdiff sponsored, abiword built, bug fixed! Easy, isn't it?
  30 [21:13] <warp10> And please, feel free to ask question in #ubuntu-classroom-chat , just prefix them with "question:"
  31 [21:13] <warp10> Anyway, today we tend to prefer the new Ubuntu Distributed Development paradigm. As you know, it uses bzr branches rather than downloading source packages from archive, giving us a bunch of advantages compared to the good old Debian way.
  32 [21:14] <warp10> barry had a great session yesterday about this topic, showing you and all the (few) commands and the workflow you need to know to propose a bugfix.
  33 [21:14] <warp10> Let's see another bitesize example, using UDD this time. Please, head your browser at maximum warp speed toward
  34 [21:14] <warp10> "canceled" or "cancelled", that is the question! (cit.) We had a sort of philological discussion here! Looks like both are fine, but the discussion lead us to say that we want to use "canceled" consistently across the whole program.
  35 [21:15] <warp10> You could fix this bug with `apt-get source update-manager` and than following the workflow we saw in the previous bug, but Daniel Polehn decided to do Ubuntu Development on steroids, using bzr.
  36 [21:15] <warp10> Downloading the source branch is very simple: `bzr branch ubuntu:update-manager`. This command will download the branch, ready for development, with debian/ directory included and applied already.
  37 [21:16] <warp10> The inconsistency is in DistUpgrade/, so we patch that file, then we add the usual entry in debian/changelog. You can see Daniel'swork in the branch he proposed for merging here:
  38 [21:16] <warp10> We are almost done! Enough we commit the patch with the usual `bzr commit` and then upload our new branch and open the merge proposal.
  39 [21:17] <warp10> This can be easily done with bzr lp-done, which will guide through the process within your browser. More information about uploading and sponsoring of merge proposal here:
  40 [21:17] <warp10> Of course, don't forget to test your work! bzr builddeb will help you generating both the source and debian package.
  41 [21:17] <warp10> Any question so far?
  42 [21:18] <warp10> Next bug will allow us to talk about a very important topic: working with upstream.
  43 [21:18] <warp10> As you all know, Ubuntu is built upon Debian, and very often we import both the packages and bugs from there :)
  44 [21:18] <warp10> Therefore, it's often a good thing to send back our patches to Debian. There are a lot of good reasons to do this, someone of them were discussed by Daniel in the first session of UDW.
  45 [21:19] <warp10> Let's see an example of good cooperation with Debian:
  46 [21:19] <ClassBot> PaoloRotolo asked: How I can find the FTBFS bugs on Launchpad? There is a list?
  47 [21:20] <warp10> PaoloRotolo: very good question
  48 [21:20] <warp10> PaoloRotolo: ubuntuwire is plenty of resources about QA and FTBFS
  49 [21:20] <ClassBot> There are 10 minutes remaining in the current session.
  50 [21:20] <warp10> PaoloRotolo: point your browser to annd especially to
  51 [21:20] <warp10> so, back to the bug above
  52 [21:20] <warp10> We have a problem with xemacs21 info pages here, and debian has the very same issue. This is a very ancient bug, but don't care, we are interested more to the "spirit" of this bugfix rather than to technical aspects.
  53 [21:21] <warp10> Scroll through the discussion in this bug report and go to comment #9. Ralph Janke proposed a debdiff here (generated in a very similar way to how we saw in the first bug). After attaching the patch, Ralph answered to the debian bug too (, informing the debian maintainer that a patch was available in ubuntu.
  54 [21:21] <warp10> Actually, the debdiff got improved in the following days, and eventually arrived to an optimal version. This debdiff was used by the debian maintainer to upload a fixed package in Debian. Later, the package was synced from Debian, and the fix arrived in Ubuntu as well.
  55 [21:21] <warp10> Don't you think this is a great way of working with bugs? This way we avoid adding a useless delta from debian, give back something to debian, improve our relationships with our upstream, allow other debian derivatives to take advantage, and even more.
  56 [21:22] <warp10> Actually, we can even go more far away, suggesting patches to the upstreams of our immediate upstream Debian, like we did in this bug:
  57 [21:22] <warp10> The problem here involves GNOME, so it's worth sending a patch to GNOME itself, rather than sending it to Debian only.
  58 [21:23] <ClassBot> kelemengabor asked: what should I do if I want to hack on a particular package, but its bzr branch is outdated? like, Transmission in Precise.
  59 [21:23] <warp10> kelemengabor: Just stick to the good old apt-get source and grab it straight from archive
  60 [21:23] <warp10> So, back to the bug. IT is a little bit nasty here, and involves some advanced knwoledge about gdb, but we don't care this so much: the Internt is plenty of resources about debugging with gdb.
  61 [21:24] <warp10> As you can see from the debdiff at comment #14, the patch is so small, but involved a little bit of work to get there and to understand what was going wrong. Don't worry, you absolutely don't need to be a gdb master to be a great MOTU.
  62 [21:24] <warp10> You need good communication skills, instead, and Scott Howard reported the bug to the GNOME bug tracker ( and added his findings too, giving a great help to the upstream developer to write a patch.
  63 [21:24] <warp10> This way, the patch got integrated from GNOME and in a few days flowed downstream to Debian and Ubuntu. That's great!
  64 [21:25] <warp10> So, all in all, what we learn from all of this? A lot of things:
  65 [21:25] <ClassBot> There are 5 minutes remaining in the current session.
  66 [21:25] <warp10> 1- fixing bugs in Ubuntu is easy and makes lot of people happy! :)
  67 [21:25] <warp10> 2- it's not a matter of a being a great programmer. You rather need good communcation and detective skills
  68 [21:26] <warp10> 3- you are not alone! Your fellow ubuntu developers and sponsors are there to help, teach you and give great hints to improve your work. Don't hesitate to ask in #ubuntu-motu or ubuntu-motu@ if you are in trouble!
  69 [21:26] <warp10> 4- upstreams matter. Don't add useless deltas from debian, rather cooperate with debian developers to get the best for both worlds.
  70 [21:27] <warp10> For more information about Bug triaging, please refer to:
  71 [21:27] <warp10> Another interesting wiki page about bugfixing is:
  72 [21:28] <warp10> And of course, the main entry point for everything about Ubuntu Development:
  73 [21:28] <warp10> Ok, guys, this ends our travel across the bugfixing world
  74 [21:28] <ClassBot> pawel_st_ asked: kelemengabor realized that a package was outdated in bzr branch. Why is that, do you always have to check if apt-get source provides newer version?
  75 [21:29] <warp10> pawel_st_: you will be warned by bzr if bzr source branch is outdated
  76 [21:29] <warp10> pawel_st_: sop, no need to apt-get source just to check it
  77 [21:29] <warp10> Ok, hope you got eager to fix bugs, guys!
  78 [21:30] <warp10> And now, everybody stand here to listen cprofitt who will tell us great things about life-cycle of bug reports in Ubuntu.
  79 [21:30]  * warp10 says "Ciao a tutti!"

MeetingLogs/devweek1201/FixingSmallBugs (last edited 2012-02-03 09:55:31 by dholbach)