 Yes. Now's where it gets hardcore. Okay. So talk starting again if you want to sit down, or if you want to talk, if you want to go outside, that'd be great. Okay. So the implementation. So we start off with mail. Mail comes in, gets through Exim, goes through Procmail, some of the spam stuff gets deleted, then it gets to receive. Receives a little script that just dumps basically the contents of the mail into a file in Spool incoming. Every five minutes at the moment, but basically every few minutes, all those things get spam checked, and most of them thus get deleted. Every 15 minutes, so three minutes past the hour, 18 minutes past the hour, 33 minutes past the hour, and 48 minutes past the hour, process all gets invoked, and that's when bugs actually get processed. You'll see the response to that on the website, so if you're really desperate to see that a bug actually gets recorded and stuff, three minutes past the hour, or every 15 minutes thereafter is when to check, you won't actually get mail then because it gets spools and just gets sent out whenever. Process all then passes to two scripts called Process and Service. I think those names are quite self-documenting. Does anyone not? Process does the general bugmails. It's the one that handles, like, the package pseudo header sort of file a bug report to submit. It handles the done mail. It handles the quiet, maintenance only, all that crap. The functionality is determined by the email address. The email address is kind of coded into the file name that's put into the Spool directory. That's pretty much it. The idea is that stores the body of the mail, maybe opens a new bug, maybe closes it, whatever else, but it's all determined by the email address and maybe the pseudo headers. And that's about it. That's what Process does. Service, on the other hand, handles the control at mail. Has everyone here actually used control at? Who hasn't? Okay, you should. Control at's a really wonderful little interface. It's usable for everyone, as long as you're kind of an advanced, like, if you're here, you should be an advanced enough Debian user to get some value out of it. And if you can help clean up other people's bugs, that's kind of a useful sort of thing to do. Oh, is that? Yes. So in Devscripts, there's the BTS tool, which lets you kind of easily send stuff to the bug tracking system control interface. But if you're a real man or a real woman, as the case may be, you should just kind of mail it directly, because that's cooler. And so, yeah, the idea is one command per line. After you say thanks or kthanksby, you can just put freeform commentary. And the idea is that kind of, it's all email, so you can CC people, and if you send it to the bug tracking system, it'll be recorded there for posterity. Okay. Errolib is another script. It's horrible. Good, he's still asleep. It kind of includes some probably Perl 4 code still. Debugs was the reason that Perl 4 stayed on master for quite a while after Perl 5 came out. Errolib is kind of particularly scary. It uses lots of global variables and stuff like that. And as far as modularization is concerned, it would be really nice to have Errolib disappear or maybe even only handle errors. And yeah, it's quite scary. If you need to go into it, you need to kind of put on your breathing apparatus and delve straight into the complicated Perl. Okay. And then obviously there's the CGI scripts. The CGI scripts are completely separate because when they were implemented, I wasn't on the Debugs team and I just thought, hey, you should be able to do this with CGI. So I'll do that in my home directory and hey, look, it works. I don't need any particular access. The common dot Perl is kind of the equivalent of Errolib dot Perl. It's meant to be a little bit more modular and tidy. And it kind of was when I wrote it, but it's accreted a little bit since then. There are three kind of scripts that actually do useful CGI stuff that are obviously up there. I hope. Good. There's the bug report one, which displays the contents of a bug report. There's the package report, which collates individual bugs that are meant to be of interest. Originally that was just for packages. It's now for basically everything. And has anyone here used packageindex.cgi? Wow. Used it. Tried it. Seen how it works. So yeah, the bug tracking system used to have just lists of all the bugs in all the packages that you could scroll to a random point, click, and then fix something, as bug roulette sort of stuff. And implementing the CGI's figure, well, complete replacements are good, and so implemented that. But there are kind of too many packages in Debian and too many maintainers and too many whatever else for it to be particularly useful. In theory, if someone wants to grab that and include some sort of pagination so that you get the first 100 or so packages and then can click to page two, that might start making that more useful. That's the sort of script that you want to look at if you want to say, I want to look at the packages with the top 10 most bugs and then I can help out with that because obviously that's where some efforts needed. Okay. Any questions so far? Okay, I say things like that because that means we're going to start going into deeper stuff. Bug number 204531. This was, I was looking for some bugs to fix for this talk to kind of give a demo. And this one seemed both reasonably old and reasonably easy. So this was a question before, I think, from someone. The sort of thing you kind of want to be able to do, or at least some people want to be able to do, and I thought was kind of interesting, is limit what, like, say, okay, I haven't been looking at my package for the last month. Let's just see only the bugs that have been filed so I probably missed them before. I might be interested in them. So the idea of this patch is just to add some parameters to the package report CGI or to the common script in this case. To say min days is 50, so I don't want any bugs that have been reported in the last 50 days or max days equals 100. I don't want any bugs that have been reported in the last 50 days because if they've been that old, then obviously I'm not going to fix them anyway. Okay. So this bit here is the changes to the package report.CGI. It basically just says, get the parameter max days, default to negative one, get the parameters min days, default to zero, and then pass those through to common.perl. Okay. Can everyone kind of understand or relate what I just said to the scripts up there, to the changes up there? If you can't stick up your hand. Okay. So then the real meat of most of this stuff goes in common.perl, which is kind of getting a bit cludgy, but it lets the actual CGI scripts mostly worry about the HTML rather than the fiddling with the bugs. So the first bit just says, okay, if I get told that the min days option is this value, then I need to store it in this variable. Then the interesting bits down the bottom basically just changes to the function that gets the interesting bugs and says, okay, so the bit right down the bottom says, okay, if the bugs this old, dividing by the appropriate factor to convert seconds since the epoch into days, then I'm probably not interested in it, or if it's not old enough, then I'm not interested in that case either. So that's kind of the level of hacking you need to do to change the CGI scripts. The bit in the middle is the kind of cludgy thing so that if you're clicking between bugs, you can kind of keep the same options. In theory, that would probably be much nicer to do it with cookies. Back when CGI scripts were implemented, cookies were evil. Does anyone remember the good old days when cookies were evil? Yeah. Yeah, unfortunately they're not anymore. So some of the things that would be good to do with cookies are kind of the configuration sort of stuff. So one of the options DebBugs has is an option say repeat merged equals no. So you only see one copy of each of the merged bugs. If you get lots of duplicates filed, that's probably handy. Another one is an option to say reverse equals yes, which will let you read the actual bug report messages in blog kind of order. So the most recent message first. And that's the way the bug tracking system always used to be, but kind of no one actually likes as far as I know. And those sort of things would be really useful to do as kind of cookies so that you set it once. It's a personal kind of setting. It's not reflected in the URL at all, so you don't have to worry about pasting it in places like that. And that's kind of been on the drawing board for ages, but needs someone new and enthusiastic to implement probably. Okay. Anyone want to ask some questions about that? Okay. So one of the other scripts that often requires hacking is the server script. It's the one that controls what you can send to control. That was a bit redundant, but hey. So here's an example change for it, which is just to allow you to say, say K thanks bye instead of just thanks at the end of your message to go on and talk about whatever. There are certain groups of people who like to say K thanks bye. Yeah, so we need more of it. Oh, yeah. I don't think that would be appropriate for the kind of demeanor we're trying to present with, Debbie. If you wanted to say fuck off in your private web log, on the other hand, that would be fine. Okay. So the way the server script is structured, which you might be able to infer from that, is it's basically just pauses through each of the lines in the mail to the control app and tries to match against a command. So the simplest command there is just the stop quit thanks bye whatever command. And it's obviously the first. There are other ones like obviously turning on debug information and all the other commands. So most of them, which you'll see later, also have to do things like actually change bug reports and use the horrible error lib stuff and have to indicate that actually this line was okay. You don't need to complain about it in the transcript and whatever else. You can see there is a transcript function there, which is what actually replies to the, is included in the transcript reply to the person who failed control at bugs.debian.org. That's the way you kind of give feedback to the user. Okay. Does everyone think they can cope with making that sort of change? Does anyone not? Excellent. We're full of hackers. Okay. Is Joey Hess in the audience? Not as far as I can see. This is Joey's pet bug. He filed it about three years ago. He then got bored with all of us ignoring it and replying to the bug and decided, oh, well, they're bugs. Yeah, I can hack on that. And so he did. So the idea behind this is basically, I'm sorry. I'm missing, aren't I? Sorry. Just pretend I've said that in five minutes' time. This is bug subscriptions. Has everyone heard of packages.qa.debian.org? Has everyone used it? Yes. The idea has done an NMU and not used it. Shame. Shame on you. So basically this is the half-hearted attempt that was done by Raphael, I think, a couple of years ago now, which lets you subscribe to all the bugs against a package, which is really useful for an NMU so you can see, oh, my God, people are suddenly filing heaps of bugs after I NMU this package because I screwed it up completely. And the way this works is just, it sends copies of each of the mails to a particular address on packages.qa.debian.org. So you can see the g-subscription domain. All the configuration for debugs is from etiquette-debugs-config. It's basically just a Perl script or a Perl script fragment that sets a bunch of variables like g-subscription domain and other ones, which we can't mention in polite company. And so in theory, most of the configuration stuff is actually changeable to not refer to Debian. In practice, most of the CGI stuff is hard-coded, so it's kind of difficult to use outside of Debian. That was much better in the static HTML days. It would kind of be good if someone was really excited enough about making debugs a general solution to actually work on that and to actually work on that and make it generalizable and make it kind of relevant for other people so that it's not just people saying, oh, my God, we can't work on Debian because the bug tracking system is broken. We should hack on it right now so that there's actually some kind of momentum behind it. Okay, now we're onto bug dependencies. So bug dependencies is the sort of thing that lets you say, okay, we've got this release-release-etch bug, but we can't actually release-etch until these other bugs are finished. And how do we track that? At the moment, obviously, we track it via the release-critical-bugs page or some kind of separate hacky sort of thing. Joey's kind of wanted to have this fixed for quite a while, and his latest impetus for it is the Debian installer stuff. So Debian installer can do a release when these bugs are fixed or is blocked by these bugs in other packages because they're completely broken or just screwed up. And so the issue is kind of, I want to be able to track these in the bug tracking system. I don't want to have to keep it in email or something where I'll lose it. I want to be able to just send it off and have other people follow it. So the question is kind of, what do they mean? How do you manage them? And what sort of syntax are we talking about? What they mean is kind of, this bug can't be closed until these other bugs are fixed. Or that's what it's kind of being taken to mean. How do you manage them? So you start getting issues like, what about circular dependencies? Do we worry about that? Or do we just let the people who are manipulating the bugs worry about that? Because if you block the done message from a bug and then have it depend on something that depends on it, then neither of them can be closed. So there are questions if you upload a package that claims to close the bug. So there are questions like that that you need to consider if you're going to hack on Debugs. And one of the trickiest questions is what happens when you merge things? So if you've got one bug that depends on another and then you merge it, what happens then? Does it kind of depend on itself? Or does the dependency disappear? What happens if you've got a few bugs that depend on various things? Do you merge the things? Do you just refuse to merge the two bugs? So is everyone aware of what sort of things happen at the moment with mergers? So if you try and merge a normal and a wish list bug, what happens? At BAFs. If you try and merge a bug that's tagged patch and a bug that's tagged security, what happens? Yes. So the two bugs get merged, it doesn't complain and it will give both bugs both tags in future. One of the things which starts causing problems with the dependency stuff is you also have problems with the clone command. Who here hasn't heard of or used the clone command? Don't be shy, stick your hand up. Clone. So the clone command I made up a little while ago to try and make it easier to do installation reports so you can start off with one bug, then clone it into four or five different bugs, reassign them to other packages and keep on working. For dependencies question. Just before I forget, if I want to clone a bug, I always send in the bug and then the next 15 minutes I end up checking my inbox until I finally have the ID. Would there be a possibility in the future to actually file two bugs with one message? I've never heard of that ID before. I don't see why it would be impossible. I'll file a bug. I'm not sure that it wouldn't be better to just have it be much easier to find out the ID you're going to get rather than waiting for a response mail. Why do you want to do the cloned bug as opposed to filing the same bug on multiple packages? You do know you can specify multiple packages on the bug? For everyone who didn't hear that or didn't know, you can file a bug against multiple packages. So say package colon I don't know general comma base comma x11 comma whatever. I'm sorry, Brandon's sitting right in front of me. It's very hard to think of random package names. The other thing you can obviously do is instead of just cloning you can file multiple bugs and then have dependencies between them if you want to track them that way too. The issue with clone and dependencies is then that if a bug depends on a bug that is then going to be cloned, does the old bug now depend on both of them? Does it depend on the first one? Does it depend on the second one? These are the sort of issues that make adding new fields to bugs not necessarily difficult but kind of requiring a little bit of thought up front. So the way that isn't quite Joey's patch but is the way that kind of seemed more slightly more intuitive afterwards was the commands on the bottom there. So I suppose I can point to them with that, can't I? So the theory with those sort of things is that you say I want to block the closure of this bug, number 123456 by waiting for this other bug to be fixed number 345678 and if that turns out to have been a mistake then I can unblock it later. What do people think of that command? Does that seem kind of easy to understand? And in particular does it seem easy to understand which one's going to be blocked and which one isn't? Hands up if you think it's a reasonable thing. Put your hands down, hands up if you find it kind of confusing. The ones we've had before that would have been the other way around. Small suggestion could you add support for with as a synonym for by? I mean somehow I would just... Block 123456 with 345678? Yeah, that would be quite easy. Can you message that on IRC? Do you have net access now? Can you message me that on IRC please? Which number? I don't care. Okay. So the error-lib changes are the first ones because they're kind of easy for a change. And the only change there is that you need to add a couple of fields to the summary information. So you need to have links both ways so that if you close a bug you can find out which ones it was blocking and if you try and close a bug you can say, oh no it's... Okay, here we go. I've got 15 minutes left. And you need to be able to go both ways so you need both fields. And then you need to keep them in sync as well. This is the same problem with merged bugs there but it's slightly more complicated for dependencies. Okay. The bug report CGI change is fairly simple. You need to actually get the summary information which is done elsewhere and you need to look at it. So you need to have a look at the block by status and then you just need to put some HTML output. You can... If you want to look at the... an example of this, there's some bug which number I've forgotten. Crap. The examples of these are currently on slashtalkslashbugreport.cgi on the bug tracking system. Okay. The service changes are a lot more complicated. As you can see, it adds a new command. So that's also a line at the top. And then it parses that. So changing by to support by or with is obviously just a matter of changing by or with to the appropriate regexp. You then kind of parse that and you then need to go and look for merged bugs so that if you say I want to block this bug with these things, then if that's merged with five other bugs, you've got to handle updating all those five other bugs as well. And if some of the bugs don't exist, then you probably want to complain about that. In this case, it just continues after complaining as long as it can. Okay. So some more transcript information report these bugs were blocked by these things so that if you later have find you screw up, you can just go back and change it back. Okay. So you'll see in here as well that there's a couple of these strange things called cancel bug and get bug. They're error-lib functions that just manipulate global variables that you have to be kind of careful with. And yeah, that's basically the way that you actually get at bugs. The merged bug stuff is kind of handled in there as well as long as you tell it about which bugs that you merged with. Okay. So the other thing that the control interface does is that CC's maintainers of bugs that you've modified. So there's those sort of commands there too. Yeah. So I'll try and go through this fast-ish. And you can obviously see that there's other error-lib stuff in there. And that's about the extent of the changes to service. They're particularly complicated because the dependency stuff is kind of complicated fundamentally. And you need to work out how you want to handle stuff. This is only the first half of the dependencies patch. There are some other things that clean up some of the behavior. And so yeah, this first section just changes the... This bug is blocked by this other one or these other ones. So basically after you've done that you then need to update the other bugs. And if you've removed a dependency, if you've removed a blocking, then you need to remove it from the other bugs. If you've added it, you need to add it obviously. Okay. So that's actually now in the bug tracking system. So you can use that right now if you like. It doesn't actually display in the CGI scripts because I haven't modified the CGI scripts. I've just put those in the talk sub-directory. Okay. We're going to skip that one. So the other cool thing is bug subscriptions. Who here would like to subscribe to an individual bug? Apparently you can probably do that as of this afternoon. Do you want to come up and talk about it? So hacking last night we've had some people who decided to kind of implement a really crap solution to this which lets you subscribe anyone to it without asking confirmation. That's kind of the ultimate denial of service thing. And naturally one of our listmasters was kind of unimpressed with that sort of stuff. And so we've now got a semi-proper implementation. Yeah. So the basic idea is that we're taking the mail into the... Say your name. So for those who don't know, my name's Don Armstrong. So the basic idea is we're taking bugs or the messages that you send to the bug so you can subscribe to a bug by sending a message. If you want to 7-subscribe at donbugs.donarmstrong.com we're testing it on there just in case something breaks so people can actually continue to send real bug messages. So the messages come in. They get processed through received and process all calls process. If the message is sent to the appropriate subscribe or any of the other list aliases then it gets kicked out from the BTS directly to the listmaster... Or to Murphy. Yeah, to Murphy. Sorry, not the listmasters. They don't need any more mail. And so then it'll automatically get added to a mailing list and you'll get the subscription message so you can confirm. The confirm message again goes right back to the BTS and then any messages that would have gotten sent to bugstist will actually get sent as well to anybody who is also subscribed to the bug. So I guess you guys want to talk about the list? Yeah, so on the other side what we've done is anytime someone tries to subscribe to a bug it checks to see if there's a mailing list. If there isn't it creates a list for that bug and then allows you to subscribe or unsubscribe from it. Every time a message comes in from the bug it's posted out to people. So that's pretty much it really. But it works. So it's ready to go on the list at devin.orgside and we're going to corner AJ later on today and either take his laptop or make it type the correct commands. Dare touch my laptop. Right, so you'll be patching the stuff for us. Alright. If anyone has any questions about that can you ask? So that should be in theory working I don't know during the week at the very least. We've had a patch for the bug subscriptions for a while now and it's kind of languished because turning the dev bugs into a mailing list manager would kind of suck and be kind of complicated and probably be done badly but being able to pass it off to a mailing list manager like an actual mailing list manager is much nicer. And so yeah, the nice thing about dev bugs is that it's kind of not really maintained so there's no real possessive sort of feel over it. So if you do start patching dev bugs you've got a pretty good chance of being co-opted into the team. Joey Hess managed to resist. He's the only one so far. Okay, how long have I got left? Okay. Either questions or we can go quick little bit over version tracking. Version tracking is probably more interesting but if anyone's got urgent questions stick your hand up right now. Good, version tracking. So version tracking is the next big thing in the dev bugs universe. The idea is to make it so that you can use experimental a bit more effectively and you can use testing a lot more effectively and you can manage the bugs in testing a lot more effectively. The kind of question that inspires version tracking is the question of when is a bug actually closed? Historically it's just been closed when it's fixed in unstable apart from a few ones which have to wait till stable because the submitter's really whiny about it. But we've also had other things like should a bug be closed when it's fixed in unstable or only when the maintainer kind of acknowledges the fix. And we've had the fixed kind of severity in the past and the fixed tag now to kind of handle that and it kind of works but if say someone doesn't happen to actually monitor their NMUs and upload and acknowledge the bugs then they all get lost in the the new bugs kind of get lost in all the NMU crap. And there are kind of similar things with do we want to worry about when the bugs fix in unstable or when it's fixed in testing? If more stuff has to happen to actually get it fixed in testing than unstable and maybe more discussions needed then I don't know maybe we need to keep the bug open a little bit longer and active. And the other thing is sometimes users don't actually care when it's fixed in unstable they care when it's fixed in testing or in stable and they can actually get at it and if the bugs closed when it hits unstable they get no further notification when it propagates up. And so the question then is why do we really want to worry about defining when it's closed like taking the fixed in taking an experimental tag and a fixed in experimental tag and then adding them together and say oh well it wasn't in anything else so it must be able to be closed now. So why do we want to bother with that sort of complexity when we've already got all the version information we know which version of which packages in which distribution and why don't we just kind of collate that information and put it together. And so in Oslo Colin and I kind of worked through the various thorny issues in this and came up with an implementation that well Colin mostly came up with the implementation that was delayed till kind of surge released which it now has. Unfortunately Colin's very busy but yeah in theory this is going to be the next big thing. The version tracking then will mean that basically messages to done will require a pseudo header to indicate the version that the bugs actually fixed in at which point normally the bug will just be closed as long as it's fixed in unstable. The tracking issue then is that the tags will be kind of reinterpreted to say that if you have a tag against a bug that says I applied a testing then the bug won't be archived until it is also fixed in testing. And in theory this should work fairly well there are lots of complications in dealing with kind of the different versioning and changelog so you can't just say this version is less than this one according to d-package therefore the greater version fixes all the bugs in the other version. So there's kind of the whole reopening issue there which in theory should also handle the maintainer fixed bugs and the enemy not fixed bugs sort of thing. Okay is there anything obvious that I haven't mentioned in that that's burning people up? Yes. I have a little more detail about how it knows what versions of a package a bug applies to because just because somebody filed a bug against 4.30-1 doesn't mean it didn't exist way back in 4.10. That's very correct. That's a big concern a lot of people have. I don't have that concern. The way that DebBugs knows what versions how the history of a package so it knows that 1.01 is based on 1.0-0.1 and 1.0-1.1 and 1.0-1.1 is based on 1.0-1 but 1.02 kind of skipped the enemy entirely is by having Niraffe and Katie kind of just send that information to DebBugs. Now the question that comes up is that's going to be inaccurate. You might not notice a bug until it appears in version 3 but it was actually in version 1 and that's true. It will be completely inaccurate. You might not mark a bug as fixed until version 5 when it was actually fixed in version 4 just because you screwed up the changelog. I'm considering that to not matter so I'm saying that DebBugs is tracking what we understand about the bug not what actually is the case. So that means that if it's only known to be a problem between 2.0 and 5.0 that's fine if it was also a problem in 1.0 then you'll need to send a message to control to indicate that if you actually care about that. If you don't care you don't need to know that information. Yeah that makes sense because I mean we can't imagine in the general case that someone will actually go research the entire history of their package to find out what the earliest revision was that actually had the bug. Searching the entire history of the package is one of the things that regression tests are valuable for and it might be appropriate to have the regression test separate from the actual package in which it's fixed. But the control interface does provide the ability to diddle the minimax numbers in the rain track. So if you do do the research you can reflect that in the BTS. Okay that's cool. So basically each bug will have a new field which will say these are the versions in which the bug is known to have been known to exist so it'll be the opening versions and these are the versions in which the bug is believed to have been closed. If you then find you have to reopen it those versions will obviously have to switch around a bit. And that gets quite complicated and I don't have my notes to indicate all of little complications but we believe we've got it handled fairly well in theory. There'll probably be more problems when people actually use it so that will require some kind of testing. Probably time for one or two more questions either on version tracking or in general but if there aren't any that's fine too. Yep up the back. With the new subscribing option will submit this be subscribed automatically or do they have to do that after they've submitted the bug? So yeah one of the really crap things about their bugs is that mailing to 12345 at bugs.debin.org doesn't actually go to the submitter. You need to mail 12345-submitter which doesn't really get recorded in the bug logs. And so basically you should always mail both. One of the things that individual bug subscriptions should be good for is letting people subscribe to bugs so that they always see the information and if they weren't the person that submitted it but they still care about it as much as the submitter they can get the same kind of information. If Don's patch for the subscription to bugs actually works maybe it could be done such that the headers automatically figure reply to such that the bugs simply go back to the address and nowhere else. There's quiet, there's submitter and all that but you cannot expect people to actually think about that all the time and if I reply to a bug it usually goes to the bug and the submitter and if I'll use good mail clients then everything works okay for now but I think that a submitter should be subscribed automatically to the bug and then yeah so we've been avoiding kind of refactoring the email addresses for quite a while having like the submitter stuff is really crap we've cleaned it up very slightly a little while ago not that you'd notice and the bugs but the bug subscriptions should in theory be helpful for that but they were implemented at what 3 a.m. or something last this morning so I haven't had a chance to talk to Colin and everyone about what the best way of handling the sort of stuff is is there another question time for or are we done no we are running out of time sorry but at least there was one question perhaps you can ask them in the lunch break yep okay our idea for the subscribing the submitter is since not every submitter wants to be subscribed might be a mass mailing thing to have a pseudo header and that's that's whether you want to be subscribed or not and that's all and we can try to make report bug support that so you can just tell report bug okay I want to be subscribed to all bugs I submit or I just don't want to and that would solve that problem I guess but we have to talk about that okay sorry any other questions you can bug me later so thanks for nice and interesting workshop AJ next sessions will be after the lunch break at 5 to 1 if I remember correctly because he sent us a paper and you not