19:06:04 <MadameZou> #startmeeting
19:06:04 <MeetBot> Meeting started Thu Dec  9 19:06:04 2010 UTC.  The chair is MadameZou. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:06:04 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:06:13 <MadameZou> #topic How to use BTS
19:06:22 <Rhonda> Hello and welcome to this session on BTS usage.
19:07:03 <Rhonda> I'm known as Rhonda, am a Debian Developer since 2000, maintain a fair amount of packages and through that managed to gather a good knowledte knowledge about the BTS.
19:07:35 <Rhonda> … and I hope you can forgive me some of the worst typos, the network starts to behave a bit against me. I hope to not mistype too often. :)
19:08:16 <Rhonda> If you have any questions, feel free to bring them up right ahead - but please in #dw-question and prefix them with QUESTION: so they can get picked up.
19:08:29 <Rhonda> This will help us to make it a bit more coordinated.
19:09:40 <Rhonda> The acronym BTS stands for Bug Tracking System and is where Debian stores and tracks reported bugs (including wishlist reports, not only "real" bugs)
19:10:11 <Rhonda> It is mainly an email system - actually tweaking and manipulating it can only be done via sending emails to the system.
19:10:35 <Rhonda> But I would like to start with the more visible representation of it: The web interface at http://bugs.debian.org/
19:11:15 <Rhonda> Through this webinterface you can query for reported bugs quite quickly (if the server isn't too loaded) and extremely conveniently, too
19:12:00 <Rhonda> If you go to http://bugs.debian.org/ you are redirected to a page that offers you a form through which you can search - but the most helpful part of it is several redirects it offers.
19:12:56 <Rhonda> If you are maintaining packages yourself, you can go to http:/bugs.debian.org/your@maintenance.addre.ss and see all the (outstanding) bugreports in all the packages you maintain with that given email address
19:14:10 <Rhonda> If you on the other hand do report bugreports (and I hope you do and not keep the bugs you find for yourself and get annoyed with them over time because they don't get fixed) you go to http://bugs.debian.org/from:your@addre.ss to see all the bugreports that weren't fixed yet
19:15:20 <Rhonda> If you want to report a new bug though you should first check wether the bug has already got reported. For this, http://bugs.debian.org/packagename can be used as overview for all the bugreports for the given package
19:16:36 <Rhonda> Please notice that this is looking only for bugreports against the binary package. If you want to see a combined bugreport for all binary packages built from the same source package, like e.g. openoffice.org you would go to http://bugs.debian.org/src:openoffice.org instead (notice the src: prefix)
19:17:21 <Rhonda> And if you got a bugreport number you can directly go to that report by adding it to the end of the URL, like http://bugs.debian.org/12345
19:18:58 <Rhonda> On the overview pages you have at the top grouping of bugreports with links inside the page, and at the bottom another form which helps you to change the view with respect to different aspects.
19:19:42 <Rhonda> Also please notice that on the overview page there are sometimes pretty cryptic characters next to the bugreport short descriptions.
19:20:13 <Rhonda> You can hover with your mouse over them to get a tooltip, and you can click on them to receive a popup with some further information about the bugreport at hand.
19:23:18 <Rhonda> Alright, this is the short abstract about the web interface. Again, it's only a query interface.
19:23:29 <Rhonda> So feel free to click around, dig around - nothing bad can happen. :)
19:24:26 <Rhonda> So we are coming to bug reporting. For this you need an email client, or much more conveniently, use the "reportbug" tool.
19:25:11 <Rhonda> reportbug is a textbased tool, there is also reportbug-ng which is a graphical interface that aims to do the same job but is still a different tool.
19:25:51 <Rhonda> Both do require a local MTA (Mail Transport Agent) like postfix, exim, or ssmtp.
19:26:35 <Rhonda> I won't go into details on how to configure them, actually it's quite helpful for some to have one locally so they can write mails on their laptop when they are offline and they get sent when they go online again.
19:27:12 <Rhonda> Even though when you don't have a local MTA, reportbug still is *extremely* useful.
19:28:01 <Rhonda> Because it has a --template option. This will help you produce information for the bugreport that the package maintainer would otherwise request anyway, like dependency information or similar.
19:28:46 <Rhonda> Just run reportbug --template package (with a package name that you have installed) in a terminal. Don't worry, it doesn't do anything harmful, it just will spit out some lines of text. :)
19:30:17 <Rhonda> There are several important things that will give you an idea on what to do, like where to send the email to: "To: Debian Bug Tracking System <submit@bugs.debian.org>"
19:30:35 <Rhonda> The submit@bugs address is where new bugreports are mailed reported at.
19:31:12 <Rhonda> Obviously in your bug email you should set a helpful and descriptive bug title that gives the package maintainer a first idea of what the problem is.
19:31:57 <Rhonda> Then there is another block that starts off with Package:, has a Version: and a Severity: line
19:32:24 <Rhonda> The Package: and Version: lines should be put into the first lines of your bugreport, into the mail body, where you usually would start off with "Dear friend,"
19:33:23 <Rhonda> The Severity: line is optional, you can leave it off if it is a "normal" bugreport.
19:34:06 <Rhonda> The severity can have different fixed levels, from grave, critical, serious, over important and normal to minor and wishlist.
19:35:35 <Rhonda> The first three (grave, critical and serious) are considered release-critical and define a special group of bugreports. If in doubt, do not use them unless you are sure what they mean, some people might react quite jumpy if they are used and the bugreport isn't really that severe.
19:35:58 <Rhonda> I will mention the special meaning of release critical bugreports a bit later.
19:37:06 <Rhonda> wishlist is the severity for enhancements that you would like to see in a package. Some package maintainers might suggest to you to report them directly to upstream, be prepared for that - even personally I consider a package maintainer to be a binding chain and proxy between our Debian users and Upstream developers.
19:37:44 <Rhonda> About reporting bugs, this is also documented in http://www.debian.org/Bugs/Reporting so you can check it on that page if you don't want to dig in the IRC logs later on. ;)
19:38:19 <Rhonda> <aghisla> QUESTION: is there a rule for the bug title?
19:39:19 <Rhonda> aghisla: In general no. Some package (or rather, pseudo-packages) do use the bug title for automatic processing and prefer special formating inside.
19:39:48 <Rhonda> Usually those people are aware that it's not as easy to get that knowledge around so they don't get jumpy when you fail that.
19:39:56 <aghisla> thanks :)
19:39:59 <MadameZou> < komunista> QUESTION: who and how can change the Severity of the existing (previously reported) bugreport? thanks :-)
19:40:01 <Rhonda> One of these special (pseudo) package is ftp.debian.org
19:40:48 <Rhonda> They have special requirement for the topic so they know what to do just by looking at the title of the bugreport instead of going through the body, it's just additional information.
19:41:14 <Rhonda> komunista: This brings us to the next special mail address, control@bugs.debian.org  :)
19:42:32 <Rhonda> So far we gone through querying for bugreports, and reporting new ones. For reporting, just again as reminder, try to be as descriptive not only in the bug title but also in the body of the bugreport, and it would be great if you could include a recipe to reproduce your bug.
19:43:42 <Rhonda> For tweaking bugreports, there is like said the control@bugs.debian.org mail address.
19:44:11 <Rhonda> The whole bug tracking system is open to anyone, as is this mailaddress. This means, everyone is technicly able to tweak any bugreport
19:45:26 <Rhonda> So And the control address is where the fun starts. ;)  It also works like the submit address on the first lines of the bugreport.
19:46:03 <Rhonda> The documentation for the control mail address can be found on http://www.debian.org/Bugs/server-control
19:46:49 <Rhonda> The syntax is usually "command bugnumber arguments". The amount of the arguments vary by command.
19:48:16 <Rhonda> So with "retitle 12345 new title" you set the title of the bugreport 12345 to new title.
19:49:00 <Rhonda> Don't worry, you can't do it for that bugnumber, that bug is archived already. You can tweak only not-already archived bugreports. :)
19:49:31 <Rhonda> The commands usually used are reassign to state that a bugreport is in a different package.
19:50:21 <Rhonda> This command takes a second argument after the package name: A version number. If you know which version of the other package is affected by the bug it is very useful and needed to add the version so that version tracking can continue to work.
19:50:48 <Rhonda> I will explain version tracking a bit later, and did dig up some examples where you can see how it is working. :)
19:51:13 <aghisla> <komozo> QUESTION: how important is the "APT Policy" for a bug report ?
19:52:27 <Rhonda> komozo: Actually, I'm not exactly sure what you mean with "APT Policy" in that respect, can you explain it a bit further? It is the first time I've heard that term, especially in connection with bug reports?
19:53:36 <Rhonda> The "tag" command helps to classify the bugs. Actually on submitting a bugreport you can also add "Tags: " to the pseudo headers of the submission and already set specific tags for a bugreport.
19:54:37 <Tolimar> Rhonda: Maybe the "APT policy" line, reportbug usually adds when reporting a bug to a package (summary of apt-cache policy information).
19:55:15 <Rhonda> Some of the tags that are more regularly used are patch (when you add a fix for the problem with your mail), moreinfo and unreproducible (when package maintainers have troubles to understand the issue), security (when the bug is about a security issue), and the likes. The list of tags can be seen on http://www.debian.org/Bugs/Developer#tags
19:56:23 <Rhonda> Aaah, now I see it, yes.
19:56:36 <Rhonda> Coming back to reportbug --template output. :)
19:57:15 <Rhonda> The actual bugreport should be put in *between* the block with Package, Version and Severity, and the rest starting off with System Information
19:57:56 <Rhonda> The System Information block helps the maintainer to dig up troubles that might be the cause of special dependencies or debconf related settings or used kernel.
20:00:06 <Rhonda> When the bugreport itself is very detailed, these System Information usually isn't used or needed at all. But quite often some people do submit bugreports with poor information (not intentionally) and then these System Information might give a good hint in which direction to investigate.
20:00:30 <Rhonda> komozo: Hope this answers your question well enough. :)
20:01:35 <Rhonda> Back to the control address. Mails to that address are stored in the BTS but aren't sent out anywhere special, so usually you see such control mails have Cc to bugnumber@bugs.debian.org
20:02:03 <aghisla> <komozo>: QUESTION: See here on output of "reportbug --template pakage-name" under system information :  APT policy: (500, 'stable'). the link http://paste.debian.net/102002/
20:04:05 <Rhonda> Yes, figured that now. This is the default value that stable users will send along. People might have other repositories set in their sources.list and tweaked the preferences so that packages from a specific release are preferred to get installed.
20:04:41 <Rhonda> This is apt internal information - but useful (additional to the version of the package) to the package maintainers to see in what environment the bug is happening.
20:04:54 <Rhonda> Soooo....   bugnumber@bugs.debian.org  :)
20:05:15 <Rhonda> Such mails get sent to the package maintainer (and other peoples subscribed to the address)
20:06:24 <Rhonda> If you want to subscribe to a specific bugreport, simply send a mail to bugnumber-subscribe@bugs.debian.org. You will receive an email which you have to confirm, from then on you'll receive all emails sent to that bugreport.
20:07:35 <Rhonda> You can also subscribe to all bugreports of a specific package through the PTS (Package Tracking System) on http://packages.qa.debian.org/packagename (exchange packagename with the package you want to subscribe to).  In the lower left corner you'll find the subscribe form.
20:08:30 <Rhonda> But, if people send mails to both control@bugs and bugnumber@bugs you don't want to confuse or annoy the control parser with the text that you add for the package maintainer.
20:10:13 <Rhonda> So there is this special command "thanks" that you might have noticed after the control commands. This tell the parser to stop parsing the mail from then on.
20:10:46 <Rhonda> Please be nice to the parser and use "thanks" to end your control messages. :)
20:10:54 <MadameZou> < mike_> QUESTION: Can you do all the control-server actions by using pseudo headers in an email to bugnumber@b.d.o or do you need to use control@b.d.o?
20:11:35 <Rhonda> mike_: You need to use the explicit control@ mail copy, automatic parsing isn't done.
20:12:05 <Rhonda> From what I understood it's worked on but it might take a bit to make it relieable and not catch something it shouldn't.
20:12:45 <Rhonda> Also, please notice that I always just said that mails to bugnumber@bugs are sent to the package maintainer (and subscribed people). Those mails are NOT sent to the person who did report the bug!
20:13:32 <Rhonda> This is also something that is in discussion to be changed - for the time being, you either have to dig up the submitter from the bugreport and add it explicit to the copies, or … use another convenience mail address: bugnumber-submitter@bugs.debian.org  :)
20:13:47 <Rhonda> That way you won't have to dig up the submitter of the bugreport, pretty nifty, isn't it. :P
20:15:12 <Rhonda> So this is the first part of the session, I now would like to switch over to explaining version tracking (with examples! :))
20:15:47 <Rhonda> So if you have any pending questions, please shooot now before we get distracted into a different area which is very helpful, needed and important to package maintainers
20:16:13 <komunista> Rhonda: thanks :-)
20:16:29 * Rhonda . o O ( and if you need a short break to go to the loo, I guess now would be the time for that, too :P )
20:18:45 <Rhonda> Alright, ready to rumble? :D
20:18:58 <Rhonda> So what actually is this "version tracking"?
20:19:51 <Rhonda> It means that the BTS keeps track of in which version a bug was closed, which releases it affects and the likes.
20:20:19 <Rhonda> That's why the Version: pseudo header in the bug submission is very important.
20:20:38 <Rhonda> Otherwise the BTS might think the bug affects every single version of the package.
20:21:07 <Rhonda> And this is also the place where I come back to the special bug group of release-critical bugs that I mentioned earlier.
20:21:36 <Rhonda> Because you see, bugreports can get archived after 28 days … if they fulfill some criteria.
20:22:48 <Rhonda> Usually bugs have to get fixed both in unstable and in testing to get archived.
20:23:37 <Rhonda> Of course only if they affect both releases - a bugreport that affects only unstable but not testing (because of the found version) can get archived right ahead - if it's built on all architectures.
20:24:24 <Rhonda> So the affected distributions is one criteria, the affected architectures the other.
20:24:39 <Rhonda> If both criterias are solved and fixed, the timer starts. :)
20:24:46 <Rhonda> valhalla: Guess that answers your question? ;)
20:25:29 <MadameZou> Rhonda: need to paste, anyway: this channel is the only logged
20:25:41 <MadameZou> < valhalla> QUESTION: 28 days from submission? or from last edit?
20:25:57 * Rhonda . o O ( I'm answering before the question appear. Yeah me  \o/ )
20:26:04 <MadameZou> *g*
20:26:46 <Rhonda> Bugreports can get closed in several ways. The most common is through a package upload that contains a "closes: #12345" in the changelog.
20:27:19 <Rhonda> When the package is accepted into the archive this triggers a mail to 12345-done@bugs.debian.org with Version: 1.2.3 in the first line of the mail.
20:27:45 <Rhonda> This can obviously also be done manually, so if one does send a mail to -done@bugs with a Version: header that also claims the bugreport to be fixed in that version.
20:28:12 <Rhonda> If the bugreport is a non-issue (like, a false report) then the Version: line should be NOT added to the mail.
20:28:42 <Rhonda> This difference is needed for the BTS to be able to distinquish bugs fixed in a specific version and bugs that aren't really bugs.
20:29:47 <Rhonda> The later will start right ahead with the 28 day period. The former will only start when the package in that version is in sync in unstable on all architectures and also in testing (if the bug affects testing)
20:30:30 <Rhonda> … and I still haven't touched the release critical bugreports that are thrown around anywhere. Now we reached the point where I can't avoild them anymore. ;)
20:30:58 <Rhonda> release-critical bugreports will ALSO have to be fixed for stable to start their archival process.
20:31:57 <Rhonda> So even when a release critical bugreport got closed in unstable, did move over to testing and is in sync on all arches, it will NOT get archived as long as the version tracking still thinks it affects stable.
20:32:36 <Rhonda> The BTS web interface has a very helpful feature for all of this: The version graph.l
20:33:00 <Rhonda> You might have noticed it already in some individual bugreports, it's in the upper righthand corner.
20:33:19 <Rhonda> It consists of several boxes: red round ones and green square ones.
20:33:38 <Rhonda> The green ones are those of fixed versions, the red ones are those versions affected.
20:34:09 <Rhonda> Like mentioned earlier, feel free to click around - this includes clicking on the version graphs. This will immensly enhance readability of them. ;)
20:35:56 <Rhonda> Let's take a look at an easy bug graph: http://bugs.debian.org/598274
20:36:22 <Rhonda> This graph is really simple, there can be very complex graphs with several branches around.
20:36:45 <Rhonda> You see on top the green box and also the releases mentioned (testing, unstable) and below the red one (stable)
20:36:59 <Rhonda> On the left side you see the Severity: grave
20:37:16 <Rhonda> Like mentioned, this is a release critical bugreport. This is the reason why this bugreport isn't archived yet.
20:38:19 <Rhonda> From reading the bugreport it seems to be wrongly affecting stable: icedove 3 is not part of stable, so this bgreport isn't of grave severity for stable.
20:38:48 <Rhonda> But given that one can't set severity by release this is where the also former mentioned bug tags come into play.
20:39:51 <Rhonda> There are tags for the distributions. During my work on reducing the stable release-critical bug count I stumbled upon a lot of such bugreports.
20:40:26 <Rhonda> So tagging this bugreport with "tag 598274 + squeeze sid" will mark it as _not_ affect lenny.
20:40:48 <Rhonda> If a bugreport has a release tag attached to it the BTS considers the bugs to *only* affect the given releases.
20:41:55 <Rhonda> If you have a local MTA and did set the DEBEMAIL environment variable like I do, there is an extremely helpful tool in the devscripts package: It's called "bts" - guess what it's for. ;)
20:42:36 <Rhonda> It's a commandline client to the BTS, and I just sent a control mail about this issue with submitting this at the commandline: bts tag 598274 + squeeze sid  '# not relevant for stable'
20:43:39 <Rhonda> <Tolimar> Question:  The bug is marked as fixed in 0.7.3-3, which is also the version in stable.  Why does the BTS still think it affects stable?
20:43:50 <aghisla> <Tolimar>: QUESTION:  The bug is marked as fixed in 0.7.3-3, which is also the version in stable.  Why does the BTS still think it affects stable?
20:43:53 <Rhonda> Gooood question. :)  Actually I waited for that. ;)
20:43:53 <aghisla> argh
20:44:28 <Rhonda> See the line right above that: It is also *found* in the same version.
20:45:03 <Rhonda> Given that a bug can't be found and fixed in the same version, the BTS is doing the conservative approach and removes both parts and considers them not existing.
20:45:24 <Tolimar> Thanks :)
20:45:45 <Rhonda> So when reading further down the bugreport it seems that the fixed version 0.7.3-3 was set wrongly, and we should remove it: bts notfound 598274 0.7.3-3
20:46:20 <Rhonda> Actually such things can even be chained and combined in the bts tool, seperated with dots.
20:46:47 <Rhonda> This is especially useful when doing a lot of different things at once, it does only produce one email then and not several.
20:48:11 <Rhonda> If you reload the bug page you will see the Tas are already set. Nothing else seem to have changed, has it?
20:48:26 <Rhonda> Tags are set, even
20:48:49 * Rhonda . o O ( and I hope we don't just DoS the BTS ... )
20:50:00 <Rhonda> There *has* something changed: If you click on icedove-bidiui on the top to get to the overview page of the bugs for that package, and then click on the [G|u|☺] part in the bug short description, you will see that the bug can get archived in 28 days!
20:50:17 <Rhonda> Hooray, we just managed to close a stable release critical bug, live here and now :)
20:51:16 <Rhonda> Let's try the next. Take a look at http://bugs.debian.org/606327
20:52:11 <Rhonda> Actually this bug looks a bit strange. The intial mail does contain a Version: header, but there is no graph at all, and no version information in the summary at the top?
20:52:39 <Rhonda> Let's scroll down and look what happened.
20:53:10 <Rhonda> Right after the initial mail you will notice two short snippets of "Bug reassigned" and especially "Bug No longer marked as found in versions".
20:53:50 <Rhonda> Ahah! It lost its version information because of a reassign! I mentioned earlier that a reassign can actually take an additional argument which is a version number.
20:54:04 <Rhonda> Unfortunately this hasn't been used here …
20:54:31 <Rhonda> Let's check. Now that's even more funny. The bug was reassigned from open-vm-dkms to open-vm-tools. Aren't they related?
20:55:11 <Rhonda> If one investigates further you will find out that one is the source package name and the other is a binary built from this very source.
20:55:26 <Rhonda> So actually they should have the same version information, right? So what to do now?
20:55:59 <Rhonda> bts found 606327 2010.06.16-268169-3 '# re-add version information lost in reassign'
20:56:49 <Rhonda> We will have to wait a bit for that to happen.
20:57:28 <Rhonda> Let's check the next bugreport: http://bugs.debian.org/605784
20:57:55 <Rhonda> This bug graph is just a single version. The package doesn't seem to have got uploaded since lenny was released!
20:59:31 <Rhonda> So the BTS has no chance at all just by version information anyway to distinct wether this is affecting stable or not. It needs again the help of the release tags. When readin gthe first line of the bugreport right ahead, "after upgrade to squeeze", it hints in that it doesn't really affect stable.
21:00:10 <Rhonda> So we are doing tagging it with + squeeze sid again. :)
21:02:06 <Rhonda> When we go back to http://deb.at/B606327 (this is my personal redirect service, I'm a lazy typer) we will see that a bug graph appeared, and it contains (testing, unstable) only. The bug doesn't affect stable anymore. Second stable RC squashed!  :)
21:02:51 <Rhonda> Now a a bit more tricky issue, these were all simple cases.
21:02:57 <Rhonda> http://deb.at/B507360
21:03:36 <Rhonda> This bug is marked as closed since February! That's definitely longer ago than 28 days! What's going on!
21:04:01 <Rhonda> We have a found version listed, and a fixed version in the information on the top left.
21:04:18 <Rhonda> And we have a completely red graph. Where is the green spot?
21:04:35 <Rhonda> Like mentioned, you can click on the graph.
21:05:07 <Rhonda> This doesn't give more information yet, but you can expand the graph: "don't collapse"
21:05:28 <Rhonda> Fixed in version 2.28.0-1
21:05:36 <Rhonda> Can anyone find 2.28.0-1 in that graph?
21:06:15 <Rhonda> I don't believe that I'm that blind, and I guess you all can confirm that that version isn't in the graph.
21:06:50 <Rhonda> So what happened here? As can be seen the mail wasn't closed with an upload but with a plain mail.
21:07:03 <Rhonda> erm, the bug was closed with a plain mail, of course. :)
21:07:24 <Rhonda> It can easily happen that someone fumbles with the version in there, and this seems to have been the case here.
21:08:07 <Rhonda> Because the PTS doesn't know about that version in its history neither: http://packages.qa.debian.org/g/gnome-media.html
21:08:14 <aghisla> <komunista>: QUESTION: what about „bug tracking system atacks”, for example aimed improper closing, reopenning, etc?
21:09:35 <Rhonda> komunista: Actually some spam messages managed to send mails to -done addresses. Those are usually easily catched, and given that everything can get reverted easily it's no that troublesome.
21:10:13 <Rhonda> The package maintainers usually notice those and react to them, as do the BTS admins regularly.
21:10:56 <Rhonda> The BTS admins also have the possibility to block some senders from working on the bug tracking system in case they deliberately do malicious things.
21:11:56 <Rhonda> But being open and inviting everyone to work on bugs totally outweights the troubles that sometimes pop up because of misuse of the control bot.
21:13:17 <Rhonda> Coming back to that gnome-media bug, we just need to adjust the version information. We choose the conservative approach and mark it as fixed in 2.28.1-1 which was the next uploaded version after which it claimed to be fixed.
21:14:09 <Rhonda> bts notfound 507360 2.28.0-1 '# fixing version information' . found 507360 2.28.1-1
21:15:24 <Rhonda> Looking back at http://deb.at/B605784 we see that … the version graph hasn't changed at all. That's correct, but the release tags are set, so it isn't considered affecting stable anymore. :)
21:15:31 * Rhonda . o O ( third stable RC squashed )
21:16:51 <Rhonda> Similar issue with 418597, it needs also digging around the proper fixed version.
21:17:32 <Rhonda> Actually there seem to be some more mishaps in the gnome-media package so I sent to one of the package maintainers a ping to go over them to take a look. :)
21:17:54 <Rhonda> Those aren't RC bugs, but not closed properly neither because of version tracking.
21:18:40 <Rhonda> <gregoa> hm, shouldn't that have been (not)fixed instead of (not)found?
21:19:25 <Rhonda> gregoa: Thanks for thinking along, you are of course right. Though, I won't send another control message because actually it doesn't matter. The wrong fixed doesn't affect anything, so I leave it to not annoy the package maintainers. :)
21:20:07 <Rhonda> Now to some other issues:
21:20:43 <Rhonda> http://bugs.debian.org/src:logrotate - this package has a nice amount of already fixed versions.
21:21:25 <Rhonda> When one clicks on the bug tags for the additional tooltip information one sees that they are closed since … ages?
21:21:42 <Rhonda> Now what the heck? What's going on
21:22:44 <Rhonda> Let's check on #388608
21:23:11 <Rhonda> The tooltip says Modified 1 year and 116 days ago. Wow :)
21:23:22 <Rhonda> … a fair time over 28 days, isn't it. ;)
21:24:07 <Rhonda> Let's check the buggraph. I doubt you will be able to read it, so click it. :)
21:24:21 <Rhonda> On top, (testing, unstable) in the green box.
21:24:44 <Rhonda> But what the? There is *another* unstable in a red circle further down the road?!
21:25:01 <Rhonda> Now can that be, two unstable versions?
21:25:39 <Rhonda> Let's check packages page: http://packages.debian.org/unstable/logcheck
21:26:14 <Rhonda> uups, wrong package. ;)
21:26:19 <Rhonda> Let's check packages page: http://packages.debian.org/unstable/logrotate
21:27:10 <Rhonda> If you scroll down to the end of the page you find the version information. And even in here we have a color code:  green is in sync, yellow is behind in debian revision, and red is behind in upstream version.
21:27:36 <Rhonda> We can savely ignore the m68k yellow because it's an "inofficial port".
21:28:09 <Rhonda> The culprit version is hurd-i386, it's 3.7.1-5 and that was also the version of the circle with (stable, unstable) in the bug graph!
21:29:05 <Rhonda> So what can we do? Either find a hurd porter to get the recent version of the package built, or … ask one of our nice ftp masters to remove the package on hurd-i386
21:30:30 <Rhonda> This is done through reportbug ftp.debian.org. reportbug does one guide helpfully through a menu system for this pseudo package making it extremely easy to request even such partial removals of a package.
21:32:01 <Rhonda> I usually select RoQA (Request of Quality Assurance) because the QA team is everyone, including you. Yes, it consists of everyone that cares for Debian.
21:37:25 <MadameZou> ehm, Rhonda has some network's problems
21:37:44 <MadameZou> :/
21:38:07 <komunista> nothing is perfect :-)
21:41:45 <Rhonda> Actually this package has the same problem: http://bugs.debian.org/src:distcc
21:42:16 * Rhonda . o O ( that line still was in my input buffer. Sorry for te hickup. Glad that I have a backup network through my mobile phone - took me a bit to change though )
21:43:36 <Rhonda> I did file a hurd-i386 removal request on distcc earlier today, and we have pretty quick ftp master members, it's done already. :9
21:44:04 <aghisla> cool!
21:45:14 <Rhonda> And if you click on the information on those bugs, they will be archived soonish. :)
21:46:23 <Rhonda> Btw., if you wonder how I stumbled upon the examples for this talk, I used the UDD for it.
21:47:30 <Rhonda> The UDD is the Ultimate Debian Database and it can be queried with whatever comes to mind. I did set me up two pages on my alioth acount (from where everyone can query it) to track such things down: http://alioth.debian.org/~rhonda/
21:48:51 <Rhonda> The first is the list of still outstanding stable release critical bugreports (which nowadays can also be queried through <http://udd.debian.org/bugs.cgi> by selecting lenny on top), the later is just a summary of bugreports that got closed last year already and still aren't archived.
21:50:03 <Rhonda> So, did any further questions about version tracking pop up in the last minutes while I was disconnected?
21:52:35 <Rhonda> If not I guess we can end this session.
21:53:40 <Rhonda> Thanks for your attention during this almost 2 hour session, hope it wasn't too boring and that even the old timers were able to learn a thing or two, especially about some tricky issues with respect to version tracking, which still is something rather new and a bit of confusing at times.
21:53:55 <komunista> Rhonda: nice info, thank you :-)
21:55:01 <MadameZou> ok, if there are no more questions I'll end the log
21:55:04 <Rhonda> If you are still confused about some version tracking parts, feel free to ask me anytime to dig around (and be patient with waiting for responses, can be busy at times or even (forceful) disconnected like before ;))
21:55:09 <lesleyb> Thanks for this work, Rhonda :)
21:55:27 <TetsuyO> thank you Rhonda, very interesting session :-)
21:55:30 <MadameZou> #endmeeting