Ubuntu Wiki

   1 [20:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/03/01/%23ubuntu-classroom.html following the conclusion of the session.
   2 [20:01] <Rhonda> So, let's continue with the schedule without further interruption, to keep you satisfied.
   3 === neversfelde_ is now known as neversfelde
   4 [20:02] <Rhonda> Please reminded to ask your questions in #ubuntu-classroom-chat and prefix them with QUESTION: so that ClassBot can pick them up.
   5 [20:02] <Rhonda> I'm Rhonda and I'm your host for the last session today which is about "Getting your fixes into Debian, how to make community happy"
   6 [20:03] <Rhonda> I will be your host alone, unfortunately nigelb had to rest.
   7 [20:04] <Rhonda> Anyway, I'm a longtime Debian Developer and have stumbled maintained a fair amount of packages for Debian for a long time, so I managed to get a good overview on how to work with the Debian Bug Tracking System (BTS).
   8 [20:04] <Rhonda> First let me tell you why you want to send bugreports to Debian and get fixes done there instead of in Ubuntu.
   9 [20:05] <Rhonda> You might have attended the great session of tumbleweed yesterday where he mentioned the why.
  10 [20:05] <Rhonda> Let me quote him, "we should rather report the mistake to the upstream, and we'll get the benefit of the fix, without extra effort, when the upstream releases a new version"
  11 [20:05] <Rhonda> And: "during [regular development time], any uploads to debian get pulled over pretty quickly (assuming we haven't deviated from Debian)"
  12 [20:06] <Rhonda> Having a difference within Ubuntu requires a lot of overhead because a merge can't happen automatically. It requires someone to take a look at it, requires testing, wether it still applies, and stuff.
  13 [20:06] <Rhonda> And then there is also our Code of Conduct which asks us to be collaborative, to give back.
  14 [20:07] <Rhonda> So every patch that is pushed upstream is a patch less for us to keep care of, with the additional benefit to the rest of the Free Software ecosystem.
  15 [20:08] <Rhonda> Unfortunately (for certain definitions of that word) Debian doesn't use launchpad but debbugs, a special tailored BTS done for the requirements within Debian.
  16 [20:08] <Rhonda> The first interface I want you to get familiar with is the website: http://bugs.debian.org/
  17 [20:09] <Rhonda> It offers you simply and quite convenient query shortcuts - and it's just that: A query interface.
  18 [20:09] <Rhonda> The Debian BTS is run and operated only by emails, the website is a read-only tool.
  19 [20:10] <Rhonda> But it still offers a lot: If you want to see e.g. the bugreports about a certain package, you just add the packagename to the URL, like in http://bugs.debian.org/wesnoth-1.8
  20 [20:10] <Rhonda> There you get an overview of all the open bugreports against said package.
  21 [20:11] <Rhonda> From there you can click through and end up with different queries, like for a specific bugreport (which can also be reached through http://bugs.debian.org/bugnumber, like http://bugs.debian.org/12345)
  22 [20:12] <Rhonda> Or for a specific package maintainer address, it's http://bugs.debian.org/maintainer@email.address
  23 [20:12] <Rhonda> But more interesting for you, when you are reporting bugs, probably is to query all of your reported bugs that weren't dealt with yet. This is mine: http://bugs.debian.org/from:rhonda@debian.at
  24 [20:13] <ClassBot> hugohirsch asked: I need to know the exact version of the package I'm looking for bugs in Debian, right?
  25 [20:13] <Rhonda> No, the overview page for the bugs for a package aren't for a specific version, or release. You get them all on one page there.
  26 [20:14] <Rhonda> If you scroll down to the end of the overview page you have a form where you can narrow down the list, but in general you get them all.
  27 [20:15] <Rhonda> If your question was related to wesnoth-1.8, the 1.8 is part of the package name, it's not the package version. Sorry for having used a confusing example here. :)
  28 [20:16] <Rhonda> Please notice that a source package can have multiple binary packages, and if you want an overview for all the bugs for a certain source package, you go to http://bugs.debian.org/src:sourcepackagename
  29 [20:16] <Rhonda> Anyway, like said, the website is just a query interface. The actual working stuff behind debbugs is its email interface.
  30 [20:17] <Rhonda> There is one commandline tool that is very popular because it prepares a report template for you and fills in some additional information that are helpful for the package maintainer. That tool is called reportbug.
  31 [20:18] <Rhonda> Within Ubuntu though, you need to add pass the -B debian option to reportbug, otherwise it will tell you that you should use launchpad (for Ubuntu) instead to report bugs. :)
  32 [20:19] <Rhonda> So if you run reportbug -B debian somepackage, you will be asked a few questions, an editor will get fired up into which you enter the description of the bug, and then you can send it.
  33 [20:19] <Rhonda> This though requires usually a local installed mail transport agent, which might be a bit cumbersome. But even in those cases, reportbug can be very useful.
  34 [20:20] <Rhonda> It has a --template option which can produce the template text for you to paste into your preferred email client to get the additional information for the package maintainers.
  35 [20:20] <ClassBot> hugohirsch asked: Is reportbug similar to ubuntu-bug (reporting to LP instead)?
  36 [20:21] <Rhonda> Actually I've never used ubuntu-bug, this is where I would have hoped for a person deeper involved in Ubuntu to jump in to the rescue. ;)
  37 [20:22] <Rhonda> The general overview about debbugs can be found on https://wiki.ubuntu.com/Debian/Bugs, and the specific description about the email interface is at http://www.debian.org/Bugs/Reporting
  38 [20:23] <Rhonda> Actually reporting a bug to Debian is sending an email to submit@bugs.debian.org and add a few pseudo header lines in the first lines of your mail text.
  39 [20:24] <Rhonda> The most important here is "Package: packagename" so that the BTS knows where to sort your bugreport to.
  40 [20:24] <Rhonda> There are additional ones, like "Version: 1.2.3" to note that you found the bug in said version.
  41 [20:25] <Rhonda> Then there is "Severity: important" - this tells the BTS the severity of the bugreport. Valid values here are grave, critical, serious, important, normal, minor and wishlist
  42 [20:25] <Rhonda> Please don't choose the first three unless you are very certain here, they have a special meaning, I'll return to them later.
  43 [20:26] <Rhonda> If you are uncertain, just leave it out and it will default to normal. All these things can be adjusted later.
  44 [20:26] <Rhonda> You will receive an email in return telling you that your bugreport was received and telling you the number of the bugreport, for a reference.
  45 [20:27] <Rhonda> And here we come to the control bot of the BTS, reachable through control@bugs.debian.org
  46 [20:27] <Rhonda> You can send it commands to manipulate the bugs, and for this you need the bugnumber.
  47 [20:28] <Rhonda> The documentation for that can be found at http://www.debian.org/Bugs/server-control - you can see the list of commands in the table at the top.
  48 [20:29] <Rhonda> <MickStep> Is this debian method of dealing with bugs through email descended from the days before the WWW really took off
  49 [20:30] <Rhonda> Actually to some degree, or rather not. Yes, there weren't these possibilities in the early days of html, but forms were already there.
  50 [20:30] <Rhonda> But what actually is important for us to be able to reach the bug reporters, and an email interface is very convenient in that way because email is quite universal.
  51 [20:32] <Rhonda> With the commands for the control bot you can see that you can adjust almost all values, like with "severity 12345 important" you'd change the severity of that bug, with "forwarded 123 http://upstream.bugtracker/456" you can note down that this bug was also reported to some upstream project
  52 [20:32] <Rhonda> The "tag" command is also very useful, bugs can be marked with certain tags.
  53 [20:33] <Rhonda> Commonly used ones are moreinfo, unreproducible, wontfix, patch, help, security, pending, and releasename tags, like squeeze or wheezy or sid.
  54 [20:34] <Rhonda> retitle will set the bugtitle new, in case when the original bugreporter didn't provide a useful summary in the subject
  55 [20:34] <Rhonda> With found one can note down additional affecting versions, and with fixed one can note down that the bug is fixed in said version.
  56 [20:35] <Rhonda> Though, usually when bugs get closed in a version, it is done similar to how it's done in Ubuntu: with a changelog entry.
  57 [20:35] <Rhonda> For Debian this goes like "Closes: #12345" (in Ubuntu it's "LP: #12345")
  58 [20:36] <Rhonda> That will do two things in the end: It sets the fixed version in the bugreport, and it will mark the bugreport as done.
  59 [20:36] <Rhonda> And this is where I want to start with explaining how version tracking works in the Debian BTS.
  60 [20:37] <Rhonda> Because usually, after a while, bugs get archived so they disappear from the overview page.
  61 [20:37] <Rhonda> I wrote this down in a blog post of mine last year, but I'll explain it here nevertheless. The blogpost as a reference can be found here: http://rhonda.deb.at/blog/debian/on-BTS-usage.html
  62 [20:38] <Rhonda> Bugs get archived after 28 days they are done.
  63 [20:39] <Rhonda> Though, there might be certain delaying factors here: The bug has to be done on all architectures in unstable and in testing.
  64 [20:39] <Rhonda> When that's the case, the counter start.
  65 [20:39] <Rhonda> Well, it has to be done in testing only when the version tracking also sees testing as affected.
  66 [20:40] <Rhonda> When the bugreport was filed against a version that is only in unstable and all archs are in sync in unstable the counter starts then already.
  67 [20:40] <Rhonda> Also there are these special bug severities that I mentioned earlier: grave, critical and serious.
  68 [20:41] <Rhonda> Those are considered Release Critical bugs, and such bugs have to get fixed in _all_ affected distributions, not only in the ones in development.
  69 [20:41] <Rhonda> That means, bugreports for RC bugs that are done in unstable will still stay around in the overview for the package as a reminder.
  70 [20:42] <Rhonda> Sometimes though version tracking gets a bit tricky.
  71 [20:42] <Rhonda> I've dug up some bugreports that we can take a look at to learn to understand it.
  72 [20:43] <Rhonda> And actually, I want to also mention another great helpful tool, which is parts of the devscripts package: It's called "bts".
  73 [20:43] <Rhonda> bts is a commandline client to the BTS. Actually what it does is create a mail to control@bugs built from the options you give.
  74 [20:44] <Rhonda> The former mentioned example of setting the severity of a bugreport would be as easy with bts as "bts severity 12345 important".
  75 [20:44] <Rhonda> Please notice again that this requires a local configured MTA (ssmtp is quite easy for simple sending out mails)
  76 [20:45] <Rhonda> And it takes your DEBEMAIL environment variable as email address, so make sure to set that to your preferred value.
  77 [20:45] <ClassBot> MickStep asked: That debian ssl bug was a "grave"?
  78 [20:46] <Rhonda> Quite certainly. :)  You can read up on the definitions of the servities in the BTS documentation on http://www.debian.org/Bugs/
  79 [20:47] <Rhonda> So, coming back to my examples. Let's start to dig through the overview page that I mentioned before first, explaining a few more interesting parts there.
  80 [20:48] <Rhonda> http://bugs.debian.org/wesnoth-1.8 - you see the bugreports grouped by severities. You have links to the Bugs themself in the number, after that is a box of [m| | ] which notes down some flags.
  81 [20:48] <Rhonda> If you hover the characters you get their meaning in a tooltip - but you can also click there to get additional overview information
  82 [20:49] <Rhonda> Like who reported the bug, when, the tags, and such#
  83 [20:49] <Rhonda> If you actually go to the bug page, you find overview information at the top, and a version graph on the righthand side.
  84 [20:49] <Rhonda> Red circles mark affected versions, green boxes fixed versions.
  85 [20:50] <Rhonda> You also can see the distribution parts in there to see wether stable, testing and unstable are affected
  86 [20:50] <Rhonda> Let's look at a specific bug: http://bugs.debian.org/612780
  87 [20:51] <ClassBot> There are 10 minutes remaining in the current session.
  88 [20:51] <Rhonda> You don't see a version graph here because there aren't any version information given.
  89 [20:51] <Rhonda> The total lack of version information makes the BTS think the bug affects all versions of the package.
  90 [20:52] <Rhonda> Actually, building against a package from experimental isn't a release critical bug, so what am I going to do?
  91 [20:52] <Rhonda> I call this command:
  92 [20:52] <Rhonda> bts severity 612780 important '# FTBFS against packages in experimental is not RC'
  93 [20:53] <Rhonda> Leave the page open, we will reload it in a few minutes. :)
  94 [20:53] <Rhonda> This bugreport is also interesting: http://bugs.debian.org/456558
  95 [20:53] <Rhonda> It actually does have a bug graph, and both found and fixed versions.
  96 [20:53] <Rhonda> But why isn't there a green box?
  97 [20:54] <Rhonda> If one looks close then one can see that it was found in the audacious package but fixed in the audacious-plugins package.
  98 [20:55] <Rhonda> The BTS though doesn't find any information that audacious package is fixed, and the bugreport is assigned to that package.
  99 [20:55] <Rhonda> So the proper fix to get that bugreport really done is a reassign to audacious-plugins package.
 100 [20:56] <ClassBot> There are 5 minutes remaining in the current session.
 101 [20:56] <Rhonda> Please notice that a reassign deletes all version information, so we have to re-add the fixed version afterwards.
 102 [20:56] <Rhonda> Here bts comes to the rescue again, and this is a good example for a chained command: One can give multiple commands that are sent to the control bot in one commandline. This is what I am using:
 103 [20:56] <Rhonda> bts reassign 456558 audacious-plugins '# done in different source package' . fixed 456558 2.0.1-1
 104 [20:57] <Rhonda> Actually there are more than just this bug in that state, so I rather leave this up to a team member responsible for audacious: bdrung, please reassign them all appropriately. ;)
 105 [20:58] <Rhonda> The next example is more interesting: http://bugs.debian.org/src:mail-notification
 106 [20:58] <Rhonda> You will find a fair amount of still non-archived bugs at the bottom of the page.
 107 [20:58] <Rhonda> Let's pick out http://bugs.debian.org/383159 as example
 108 [20:59] <Rhonda> The version graph is pretty unreadable here, so let's click on it to get it in bigger size.
 109 [20:59] <Rhonda> If you look closer, you'll notice something pretty interesting: unstable is listed both in a green _and_ in a red box.
 110 [21:00] <Rhonda> That's … special indeed. What's going on here? For that we use another fine resource as help: http://packages.debian.org/unstable/mail-notification
 111 [21:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/03/01/%23ubuntu-classroom.html
 112 [21:01] <Rhonda> You might know a similar page, http://packages.ubuntu.com/ offers the same service for you, it's the same codebase.
 113 === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat ||
 114 [21:02] <Rhonda> At the end you'll find that the hurd-i386 package has a different version than the others.
 115 [21:03] <Rhonda> So actually the build for that architecture is having troubles. Given that that architecture is not really an official yet, filing a bugreport against ftp.debian.org and asking for removal of the package on that architecture will fix that.
 116 [21:03] <Rhonda> … and I guess I should conclude the session, we run out of time.
 117 [21:04] <Rhonda> The fineprint is: Version tracking in the Debian BTS is still something rather new, not all Debian Developers have a good understanding of it and it needs a fair amount of cleanup.
 118 [21:04] <Rhonda> Don't be shy, feel free to ask, stumble by in #debian-ubuntu on irc.debian.org (different network than irc.ubuntu.com) and we'll try to help.