 Don Armstrong, he will be teaching us how to locate bugs using soap. Hi, for everybody who doesn't know me, my name is Don Armstrong. I am one of a couple maintainers on Debugs. I'm actually currently right now the person who's primarily active developing it. But that's not to say that I'm the only person behind the code. There's quite a few people who have developed and spent a lot of work. And another person who deserves a round of applause is Blares Blarson. He's pretty much single-handedly responsible for keeping the BTS as free from spam as it is. I don't know how many of you are aware of it, but on a daily basis we get something on the order of 4 gigabytes of non-duplicate spam to the BTS. It's probably something on the order of 10 to 40 messages get through of that, that spam every day. And he basically deals with that, updating the rules and making that all work. So if you happen to run into Blares, buy him a beer or give him a hand, because he does most of the unforgiving work that people don't see. Okay, just before I start talking about soap, I should talk a little bit about the architecture of Debugs. Just to give you guys an overview of what's going on so that things that I talk about that I assume you understand. Well, I actually told you, even though you probably still don't understand them. Basically, mail comes in. We check out all the spam. We have a series of proc mail rules too, besides spam assassin, a custom thing called cross assassin, which avoids running spam assassin on mails which matches IG, which we know already have a spam assassin score. So, I mean, if you're sending mail to us and it gives a nice spam assassin score of 20, well, we don't bother to run spam assassin over every single mail again. Spammers love to send the exact same spam message with exactly the same message ID to 20,000 bugs in one shot. So this helps us waste process, avoid wasting processor time on that. Then mail gets handled by process all. It's basically a small, purl script which shoves mail off to process and service. Service is what deals with control at and request at. So, if any time you use a control bot, that's what's talking to you. Process deals with everything else. So if you mail submit at or bug number at or bug number dash whatever at, that's all process. All the stuff that those things do interacts with a, well, kind of a database. It's basically a series of files in db-h. That also, from that, we generate indices which is used to make the queries fast. Obviously, if we were running straight through the entire BTS, you wouldn't see anything at all when you viewed a package report page. And then there's the CGI interfaces, the soap interfaces, anything else that works is built on top of that. And there's now a series of purl modules that deal with just about everything that happens in there. So if you really wanted to and you had to parse db-h because something I did or wasn't good enough or the soap didn't do what you need, there's purl modules now that can do all that for you. Okay, let's get on to what we can do with soap. There's a couple of major things that you're allowed to do currently. And this is not to say that this is an exhaustive list that I'm never going to add anything. And in fact, if anybody here has stuff that they want me to search for or be able to find using soap that I don't currently do, please file wishlist bugs for it. I'm always looking forward to making soap serve as many needs as I can possibly make it serve. Basically, because that reduces my headaches when I break the file back end or I change the CGI's like I just did. Because otherwise I have to try to support things in reverse. I had to do this for report bug in Sarge or Woody. And I'd really rather not like to have to do that again. So that would help me a lot and you a lot if you tell me, hey, I need you to do X with soap. So let me tell you what you can do. First things, you can obviously search bugs. And this is primarily bug searching and bug selection. Everything that you can do through the basic part of selection in package report, you can do using soap. It uses exactly the same methods which are exposed via soap that package report uses. Other things you can do, you can pull the bug status information for every single bug. This is exactly the sort of information that gets displayed when we do versioning, archival. This is the underlying summary file that gets ripped out by bug status. You can use to figure out whether version is buggy and do anything like that that's more in detail than finding a bug number from a bug. You can also pull user tags. So if you've set user tags and you want to know what user tags are set using soap. Another new feature you can also pull the newest bug from the BTS. So if you give it a set of bugs, it'll say, okay, these are the 10 newest bugs. It's not quite guaranteed to give you unique bugs or bugs that actually exist, but it will give you no more than that number of new bugs. Because sometimes we delete bugs if their spam makes it through submit and stuff like that. Actually, I don't think there's any spam through submit, but sometimes bugs disappear. So that would be why that wouldn't quite work. The final thing that you can do is you can actually pull the entire set of bug logs in all the records. So every bug is basically a inbox with really, really weird control fields in the middle so you don't have to do from processing. So you can make a soap call and pull all that information. So let's play with some of the other stuff. Obviously writing soap for everybody kind of sucks. You don't really care about what the stupid interface is. You just want to get bug numbers back out. So a while ago, I made a patch and Stephen Zacharoli actually made it palatable for people to BTS adding a new command called select. And so now what you can do is you can run BTS select and select bugs from a package. So let's see kind of how that works here. Let's see if I can get it. Let's find me a window that works. There we go. Let me open some terminals. Okay, so we can just run BTS select and a package, GDC 4.1, for example. So this will go out query the BTS and return us a nice list of bugs. There's a whole set of select queries that you can use. You can man BTS and search for select. And these are all the keys that are there that you can use. There's actually a couple more keys that aren't documented yet here, the one that I'll show you in a bit. But in general, this will document everything that you can use to do a select. The basic idea is if you list the same tag or the same key again, it ors different keys and if you want to or over keys make multiple select calls. It's kind of a no-brainer, but that's how it works. Eventually, if I could find some sane way to do it, I may do more complex select statements. Yeah. Video and stuff. It's not readable on the screen. Yeah, let me see. What do I have set as a font right now? Is that better? So just for the BTS record, I'll just show you what I was doing. Package, GDC 4.1. And so that selects a list of bugs. So that's just one example. So let's go back to what we were looking at before here. We can also use it to do more complicated things, like getting all the set of RC bugs. So we can do that, BTS select. And so this case we want severity, serious, severity, grave, severity, critical, et cetera. So this will give us a huge list that will scroll on for a while of bugs. So those are all the release critical bugs. Now, that also includes all the release critical bugs that are fixed, that are done, that might not be interesting. So if you want to do something more complex with that, I wrote another command called just recently that doesn't exist anywhere else, which I'll talk to you about in a bit, but let me get back to what I was talking about. So another new feature that I just added is Correspondent. If you were looking at the options bit that I just added on Package Report, which I'll hit briefly at the end of the talk, you notice that there's a new option that you probably hadn't heard about before called Correspondent. This is any bug that you've mailed. So it rips out the addresses from every single header field that I knew about and adds it into an index and tries to build basically databases of bugs that you've ever mailed. So if you want to know which bugs I've mailed in recently, we can go BTS, select Correspondent. This won't work on your version of BTS, by the way, sorry. There's a patch for it already, but it won't work. And this will select all the bugs in there anyway, which I've corresponded with that aren't archived. If you wanted to get every single bug that I've emailed with that mail address, you could also go archive both, and that will give another set of bugs. I don't use that email address all the time, so that's why it's not the complete thing, but that'll give you an idea. Now, you might be wondering what that's useful for. I'll show you some examples of why you really might care if you can't already think of them yourself. Okay, so BTS select is a tool that's useful for everybody. You don't have to necessarily screw around with soap to use it. It's pretty neat. Another thing that I just added, a patch for BTS, is status. It shows information on a single bug. I don't really sure if I like the file column thing that I invented, but whatever, it was an idea. If you want to show information on a single bug, you can just run BTS status, and it'll give you all the information on that bug. It'll probably change to being tab delineated, and I think it would be neat to make a table out of it if you gave it a bunch of bugs, but that's the idea. This is, again, the get status soap call basically made into a neat script. So, for example, we can take our little thingy here. Oops, well, so much for that. I don't spell well, so. But we can go back up here, and we can go BTS status, file. Obviously, you can select from a file. I think that's kind of figuring out how do you want to specify a standard in is always kind of lame, whatever. That sort of works, and it selects all the information on those bugs. Let me put it into less so you can see what's really going on here, and it also separates them like that. It always leads with bug number, so you could figure out your information from that. Okay, that's pretty easy. And you can probably think of other fun things to do with the select information on your own. I'll leave that to you. I mean, because it's now in a command line thing, it takes standard input, produces output. You can do all sorts of insane things with grep and cut and whatever else you need to do. Okay, let's do some more complex things with SOAP. The classic thing to ask is RC bugs and installed packages. This is obviously a thing that we already have an existing tool called RC alert or whatever it is that does a better job than the script I'm going to show you, but my script is way shorter. So let's take a look at what that would look like. Let me make this so... It's actually written in Perl, but whatever. You can figure that out. RC bugs and installed packages. I probably should make the font larger, but whatever. It's in my subversion repository, and I'll put links at the end for people who are watching on the video. But anyway, the basic idea is first we get the set of installed packages. That's probably a better way... There's better ways of doing it than using aptitude, but whatever it was what I thought about was I was sitting here two hours before the talk. Then we instantiate a SOAP request. How you do this is language dependent. If you really want to know all the funny ways of doing this, let me pull up the wiki, and you can follow along in the... I don't remember what the link is, but this page has examples. Hello, there it goes. The SOAP interface documentation has examples on how to do it for all sorts of different languages. So if Perl's not your thing, you can refer back to hit this after I'm done and switch to a language that you find sane. But anyway, we then use our git bugs thing that we did before to select bugs of RC severity. Then on all the bugs, I only pulled 100 out because it would take forever otherwise. We can get the status on all the bugs in one shot. Then loop over the status, pulling out every bug, and if a bug has a package that matches a package that's installed, then print it to standard output. So we can run this. We'll take a little bit of time, but... So this will run for a bit and thrash my disk, and then figure out a subset of 100 bugs that have RC bugs in it. So that's pretty easy. What about other stuff that we can do with SOAP? What about bugs that need help in installed packages? Well, you can already see that that's going to be just another example of the same sort of thing. Like I said, we just select tags. So let's see, RC bugs... What do I call it? Bugs needing help? Yeah. So we just again do the same thing, but instead of selecting severity, we select tags called help and do the same thing. So that's really simple. Yeah, so that's a much more useful example that would have taken me slightly longer than the five minutes that it took me to type this. But yeah, that is something that you can actually do with this. It's slightly more involved, and I can provide an example towards the end of DevConf once I actually have time to stop doing really useful things. But yeah, this is an example of a really simple script. And to do that more complex thing involving versioning, you'd actually iterate over the status bits here. And instead, at this point, you would compare the bugs to the version that you actually had installed and check is buggy at this particular version, and that would tell you. But anyway, this is just another example. And so this will also pull all bugs tagged help and install packages. And because we're doing archiving too, you're not going to see every single bug in all the BTS. You only see relatively recent bugs. So it's not as useless as it would have been prior to last year when I enabled archiving. The last thing that I was looking at was bugs that I filed that need love. So bugs filed which need love. So in my mind, bugs which need loves are bugs that haven't been... had a mail sent to them in over a year. They're getting lonely. So somebody needs to send mail to them. And since I've sent mail to them, or in this case, I've submitted them, so I should probably ping the maintainer. Probably in a lot of cases actually, these are bugs which I've submitted against packages which I maintain myself, so maybe not so useful. But anyway, this is sort of an idea of bugs that you could find that you've submitted yourself that you should maybe ping the maintainer. So all of the bugs now have a field in status called log modified. You've seen it on package report. It shows up, oh, this bug log hasn't been modified in such and such a time. Anytime the bug is modified, a message goes to it, the log gets modified. That's that big inbox of everything that gets sent to the mail. And so this will give me a set of bugs which need love because nobody's mailed them. And so again, you can see, I'm selecting all the bugs which I've submitted. So the submitter is Don at Debian.org or Don at Don Armstrong.com. Then I only rip 100 of them. And then I go through all the statuses, check the log modified to see if the mod time is below needs love, which is a year ago. And then print the bug number. So check what that looks like. So yeah, those were the RC bugs and installed packages. Only the first 100, there's way more installed than that, but bugs, yeah. Bugs filed which need love. And so the soap currently is relatively fast because it's using an index. There are some queries though that will make it really, really slow. And that's something that hopefully will put more machines or more CPUs on the CGI end so the soap becomes faster and also put databases behind it to make the queries a lot faster. But regardless, the API is going to remain the same. So queries that you write today will work tomorrow and forward. If you're going to write long standing applications though, please talk to me because there's more stuff involving versioning that I want you to do. But this is sort of a really quick introduction to it. So I should be emailing all of these bugs. They would be a good thing for me to do. Okay, so that's the end of the brief soap bit that I was going to talk about. The other stuff that I was going to mention is slightly more interesting. Well, from my perspective. But hopefully that gives you an idea of some of the things you can do with soap. You can play around with it on your own, play with BTS Select, play with BTS Status when it shows up. You can use that to find bugs that you've neglected that you've forgotten about that maybe you should get back in touch with and help them get closed. So they're happy living in archive instead of DB-H. Another thing that is... In this part, I'm going to switch more on to stuff that would be generally useful besides soap. So another thing that is extremely useful in the BTS are user tags. A new feature that I've just added called user values, which isn't completely implemented yet, but I'll talk about it briefly. And user categories. User tags is basically the ability to assign arbitrary tags to bugs. How many people here have user tags assigned to bugs in their name? Okay, so a reasonable number of people have user tags. There are some relatively popular tags that have been assigned to multiple user names. And these are them. I just did a select and ordered it by them. So these are the ones that have... For example, Origin Ubuntu has 15 different users who are using that tag for whatever reason. The same thing with Waits for Sponsor, there's seven users which are using that, etc. Overall, we have 373 unique user names which are using 3,243 unique tags. You can imagine there's no way I would ever have added all those tags to the BTS. So this is really useful. There are 57,000 or 58,000 some-odd tags on bugs. So this is a feature that gets used a lot. So if you're not using it, you should. You can assign... I should have checked that, but you can assign tags to bugs using the standard. You can set the username first to control. Otherwise, it defaults to wherever you sent the mail from, which probably isn't what you want. Set user tag. So for example, this is setting the archive user tag. You just imagine new lines where they belong. So newlineafterpackages.debian.org and newlineafterarchive. And setting the DAC tag. This is an example of user tags which I've actually set on the ftp.debian.org pseudo-package, which enables it to do useful things. Just a side note here. There are a set of users which are by default included in package queries. So if you include a query that includes ftp.debian.org as a package, it'll automatically load the ftp.debian.org user tags, and it'll automatically select them. That's why if you want or maintain a lot of packages, you want to use packages or user names like this if you want your tags to show up by default. Yes. Oh, yeah. There's missing new lines. The question was, did I need an extra comma after everyone? Yes. If I was using the BTS command line, it would have extra commas. I forgot to put the new lines in in the verbatim argument when I was typing this into latex. And I didn't look at it beforehand, so that's why it's missed out. But yeah, just imagine new lines where they belong, and that would enable you to set user tags. You don't need to do anything special beforehand. If the archive user tag hadn't existed before, this will create it for the ftp.debian.org packages.debian.org user. So that's pretty simple. Another feature that I've got most of the stuff to do, it just doesn't display anywhere useful, is user values. And this is sort of an idea to have the ability to assign arbitrary key value combinations, pairs to bugs. You're already familiar with these. This is what owner, forwarded, and stuff like that already is. That's an arbitrary key value tag. So you can set owner, and it's set to this value. You can set forward, and it's set to that value. The main things it would be useful for is in sorting of bugs, also selects, also adding more URLs to different things. So an example here, I am setting the patch location to a specific URL, which is run off the side of the page, but just imagine that there is a URL there. And so on the bug report now, that'll show up if you're using the packages one so that you could click on and go exactly to the message that contained the patch, or exactly to download the patch instead of having to, okay, the other thing is tagged patch. Let me find where it is and then which message has the patch to enable you to do that, for example. Another thing you could do is you could set a priority. Anything. It's Perl, remember? So put random data in it. Yeah. So I haven't really figured out exactly what I'm going to do as far as the sorting. I'll probably make it smart. So if it looks like everything is numbers, then it should do number sorting. If it looks like everything is string, or it looks like there's some strings, then it should do comp sorting by string. But that part isn't written, but that's what I'm envisioning having it for. So an example here is you could assign a priority to a bug, which would be your personal priority. So you could say, okay, this bug is really important for me to work on now, and so you would have a better workflow. So when you sit down on your bug list, you would know, okay, these are the bugs that I want to work on in this order. You could also, another thing that I thought about originally was the ability to sign time durations. So if you think this bug is going to take one minute and you have one minute today, then, okay, you can fix that bug in your one minute that you've got to spend. If you think a bug is going to take five hours, okay, well, then you put in whatever, 600 or something, or 300, or whatever you decided to use for your priority or your time allotment, and you can ignore those bugs, because if you don't have five hours to spend looking at the bug, why even bother looking at the bug title or even the log to figure out what in the world this bug is about? So that'll help out, I think. But it's still slightly incomplete. You can't quite set the values yet, and they don't display, although all the stuff to store them is there, so. Hopefully at the end of DebConf this will be working and actually announce it on DDA. Another thing that's existed for a while, but again, people don't use, because it's not documented well, which I'd hoped to force myself to do in the context of making this talk, but I did other interesting things instead, is user categories. User categories is basically the ability to override the default way that the BTS splits up bugs. Currently it splits up bugs by status, like whether it's fixed or not, severity, and one other thing that I'm forgetting, but yeah, tags. So those are the three things that it separates it by. You can decide that, oh, well, that's insane. I don't like this split that it's got, and I want to split it by these values instead. So this is an example of a split that I set up for ftp.devian.org. It hasn't been kept up as well as it should, but this is an example of things that you can do. So this, for example, ftp.devian.org does different things. There are times when it's asked to remove packages. There are things that are only involving DAC, the internal archive software. There are things that only involve Brittany. There are things that involve adding new sections to the archive or removing them or stuff like that. There are things that involve overriding the override file. And there are things that are just generally related to the fact that the archive or a mirror is jacked up or something like that. So these are all separate tasks that ftp.devian.org has. And different people sometimes are interested in different tasks, so by splitting them out this way you can just check out the sub tasks that you're looking at. This obviously isn't particularly useful if you've got five bugs, but if you're one of the packages who has thousands of bugs then this suddenly becomes really useful. So you can assign, remember the tags that I was talking about before, archive, et cetera, this tells it to split based on the tag, archive, remove, override, Brittany, DAC, and section and stick everything else into uncategorized. Then the user category normal is the default categorization, and this overrides what the default was. So now when you go to ftp.devian.org, first it splits by status. So that shoves all the fixed bugs at the end, which you don't want to see usually anyway, all the other bugs that are open at the top. Then it flips by the tasks and then it flips by severity. So we can sort of get an idea of what that looks like if we hadn't seen it before. Let's see. I don't know where I put that. Very slow. So if we pull up the ftp.devian.org, you can see that it's sort of split out. The things that are uncategorized at the top, these are just the bits that haven't had the user tags assigned to them already. But you can see down towards the bottom all the things that are involved involving the archive, etc. What do you have to type the text you gave as an example to give it that result? So everything that I've shown here, you would send to request at or control at, and that would add it for the ftp.devian.org user. Yes, actually I copied it out of the email that I sent to set this. Okay, can you explain what's the... If that's the correct syntax, does it care about white space? Does it really care about star versus plus sign? Yes. Can you explain that a little bit, please? Okay, so I didn't write this, so I don't even understand it completely yet. But the basic idea is the category start out with stars and how you split out each category gets the plus signs beneath it. And then you can assign the different tags inside the brackets. I will... Once I have a life or don't have a life or don't have less of a life, we'll document this slightly better. But the basic idea is to learn by example to see what we've got. But it's something that I'm going to improve. But again, the basic idea is you first have your status. So this is the normal thing. And so status is already predefined, a default categorization that already happens automatically. You're all familiar with it. This is the new one. And so the first thing at the top sets up this categorization. And it has a name. And the hidden thing tells it not to show up in the option selection, which is currently not showing anyway, but it generally wouldn't show if it was said hidden. Okay? Oops. This defines this categorization. And so the title is at the top. That's how it would be labeled in the summary. And how it's splitting on is on tag. You could split on pending. You could split on severity. You can split on a couple other things that I can't think of right now. But those are the three main ones that people use. Then each of the individual plus bits here delineates a subcategory in the package page. So the first one is that it's archive-related. And so this has the archive tag. So tag equals archive defines it. And these work in order. So the first thing it matches is where it ends up. Okay? So if you had it tagged archive and DAC, it's going to end up in archive, not in DAC. You can also, I believe, put commas in between them in multiple tags. Same thing with removal requested. The tag equals remove. Tag equals override, et cetera. And these are just, again, the titles of each of the individual sections. Okay, so on the category. Does it care about whitespace? It cares about whitespace going this way, yes. Yeah, whitespace matters. And this whitespace new line space here matters too. Yeah, it is sensitive to whitespace. Can you, can I do that on? Oh, WNPP, yeah. Sure, you can do that in WNPP. Anybody who wanted to spend the time to categorize all of WNPP could do this to split it out into different sections. Unfortunately, it cannot be easily automated currently. Is there any way that using user categories on WNPP would allow us to cause the view to be faster by having it have to access fewer bugs? Could we, like, say, hide all the bugs that had a certain tag and a certain view, and that way we could, because currently, the WNP website has a develop slash WNPP where the bugs are listed out. And one of the reasons that's needed is because the BTS is so slow to load the WNPP list. Yeah, I will show you how to make the WNPP list show up faster towards the end if I get the chance. So, but yeah, this is another thing that you could use to do that is you could just show a tag, a specific user tag that matched, which would also make it faster. You wouldn't even necessarily have to go to user categorization, but it would make the whole display nicer. So that's user categorization. Another new feature that I just added, which isn't documented yet, but it works. I tested it anyway. It works as far as I tested it, let's say, is summary. So the idea behind summary is the ability to in stupidly long threads to pick the paragraph in a particular message. There has to be the leading paragraph, but pick a paragraph in a message that actually tells you what the stupid bug is about. The title should be the shortest thing that you can manage that sort of conveys that, but sometimes it's not long enough. So summary just nominates a message in the log and says, okay, you're now the summary of this bug. It puts it up near the top of the title, and basically the way it works is you give it a bug number and the message number that you want to rip it out. It tries to do the right thing with quoted text by ignoring the first paragraph if it looks like it's quoted by ignoring the first paragraph. If it looks like it's pseudo headers or tags, it's not infallible. So if it screws up, give me an example and I'll try to make it even in those cases. If you're using the Gnu's quoting style with indenting, you're insane. It won't work for that, so I'm sorry. But everything else, it should do the right thing. You can see an example of that on that bug. Not a particularly useful example. It was just the one that I was testing with. So you can check that out. Skip something. Another thing that I just added is the ability to mark bugs as affecting another package. Somebody had asked for the feature and originally I thought, well, why would you want that? You just use blocks. But the idea is actually in retrospect when I thought about it on the plane, makes much more sense. A lot of times we have bugs in core packages that affect 8 billion other packages. And it really sucks when you're a maintainer of the package where the bug doesn't actually exist, but where it manifests, that users file bug after bug after bug after bug, which you reassign and merge into the actual bug. The way you would do that currently is you would just leave a bug there, mark it as blocking the other bug. And then you'd have to recognize that, okay, yeah, this other bug got fixed, and now let me mark my bug as closed. So with this, what you can do is you can nominate a bug as affecting other packages. And by default, well, once I have it totally working, it's a package selection list. There'll be an option to turn it off, of course, because most of us don't care what it is, but end-users are going to want to know that a particular bug is affecting another package. I don't know where the slide went, so... I was trying to find the right slide, but it appears to have escaped. So... So that's why the slides don't match. But that's a new feature. It'll be documented in the usual places on bug site in Donorock as well. Okay. Another thing that is the... Yeah. About the treatium, maybe, I imagine that then, on the bug list of the affected package, you see the original title of the bug, which often users will not recognize as the effect that it has on the affected package. Yeah. I mean, there's always a case where users are running into... But hopefully you would take and make the title of the affected bug so that blah, blah is broken and blah causes something else that causes every package to break or something like that that would make the title more accurate. But yeah, I don't know of a good... Part of the thing is it's a really difficult problem to figure out the right balance between being able to grab the user by the ears and say, yes, this is your bug. And being able to be informative for the developer looking at the bug list and saying, oh yeah, that's the problem with that bug. I will fix it now or no, I will deal with it later. And that's a really difficult thing to balance. So I mean, any better thoughts on how maybe better to do that? Maybe the answer is making the summary for that bug show up in the first page. That's definitely possible. So I'm being told that I have 10 minutes left so I will start speeding up slightly. So that would be something useful to think about. Okay, another thing that in Helsinki, BDL actually asked about and is finally starting to become moderately possible to do. It's still a little bit hacky but hopefully towards the end I'll have it so that I actually have packages like Experimental which enable you to do this is to run a local mirror of the BTS. So I don't know, not all of you are jet setters but there are lots of times when you are in some place that doesn't have internet but yeah, you've got your local VCS and yeah, you've got everything else you need but damn, I don't have a local copy of the BTS so I have no clue what's wrong with my packages. So the idea is actually pretty simple since bugs are all available via R-Sync and once I finish packaging CGI scripts and put them in Experimental we can rip all the bugs via R-Sync that we want based on whether we've mailed the bug, whether we've submitted the bug which we mailed it whether it's a package we maintain even if we haven't bothered to respond yet there's an RC bug hopefully we're interested in those bugs so any of those things you can add a whole set of selectors for bugs and for some reason you wanted them all it's again still possible to rip the entire BTS the db-dutch H right now is only like 8GB so it'll fit on just about anything you've got but anyway then you can R-Sync the bugs needed using Include with the little script that I pounded out in 10 minutes we'll pull the indexes and the version files which the BTS just needs to work you'll install the Debugs packages which ideally will have a little script that does everything above so you don't have to think and in this case I have to configure patching bits but I'll probably have it set up so that you can run a command and it'll run a little web server on 8080 on localhost or something like that so you won't even have to pittle around with the patching and say start little local BTS don't tell me pages so I'll sort of give you an idea of what the script looks like I think so here's a script that doesn't it probably needs to be slightly more made a little bit more robust but anyway it'll rip all the bugs yeah it's not executable but whatever so we'll go out pull all the bugs I've mailed etc. we'll start R-Syncing this will take a while so I'll ignore the fact that it's still going in the background and then after configuring Apache we can now look at bugs on this local machine so this is a very minimal mirror that only has these bugs running a small set of the CGI scripts and if you really wanted to do it right this second you can let's see that's the Apache config that does it and it just running out of a the only key thing that matters is this config file which isn't very big and the fact that I have a local copy of the BZR repository of Debugs but eventually you'll just install the package hopefully by Friday I will in assuming I announce something to devil announce you'll be able to like I don't know what command but Debugs local mirror that start the CGI and it'll just work so you won't have to do all this insane stuff okay I'm thanks some more stuff just to go run through this as fast as I can there is a bof and anything that I don't talk about I will come back and pittle about later and then I'll go back to the translation you guys won't see but it makes my life slightly better it reduces the number of times I break the BTS and the length of time that I break the BTS and the number of times that I break the BTS immediately before going to bed or disappearing from the face of the planet so basically now everything or most things are modules they relatively sane as far as pro goes there are archival most of you already know about that that was last year that I did it the other thing that's there is the new package report select options which why I just talked about with the oring and ending so you can make really complex select strings the other thing that's really major is template support in theory since I only speak English it hasn't happened but in theory you can set the locale by some means that I haven't decided how you're supposed to do yet and you could localize most of the BTS as it is now luckily everything is in templates though so this means that you can also make changes more easily without dredging through the source code and figuring out where it is yeah the question was whether I just use languages and yeah that would be the right way for the CGI stuff the other half the question was the templates are also used for the email and that was the other part that I had no clue how to do properly so but yeah it's something that's worth thinking about and hopefully once it's the templates are slightly more content in one place code in another place it'll be something that I can give to translators and ask please make these okay summary I talked about effects I talked about and corresponded was the other cool thing all these bits work in the normal package report that you're used to so future stuff more methods control is currently being abstracted out every time I look at it I have pulled out more and more bits why this matters to you is it will enable you to do all of the control methods in messages to process or to process all so anything that you would send to the NN at bugs.diamond.org or submit at bugs.diamond.org it will enable you to set any control option this also enables me to rip out code out of process which does things like setting the package it makes it do exactly the same thing no matter whether you're using control or setting it in the initial submit message it also has the possible side effect of allowing a web front end but I don't think I'm going to allow that because I don't want to control messages with soap and most likely not and the reason is because of the whole authentication issue I it could be that if enough people decide that it's worth it to allow it with messages and authentication that I will do it the only thing is it almost assuredly will not be instantaneous so there will be some sort of delay while you sit in the hall to wake up and decide that it wants to process things because currently it's a very lock intensive process when it decides to modify messages and long competitions is a little bit annoying yeah things behind you I think that one of the things I'm most missing from the BTS is a commandainer view because a lot of our infrastructure has been migrated to have a point of view so I'm going to look at this and I need to look at 10 different pages and there are a couple of bug reports I think there was something missing on the dark side maybe yeah the main thing right now that's missing for me enabling that is an uploader's file from DAC and that's something that the FTP master team knows about and is working about making available procrastinate for another couple years and then maybe it will happen another thing that I'd like is some more integration with mole and stuff so you can put per package stuff and better statistics and documentation this is how you can help okay the source is all available my source is even available on bzr.armstone.com if you want to know what I've been working on that isn't yet committed although right now my tree is still working on the main line but as I do crazy stuff it gets more and more divergent until I drop 1000 line packages onto the bts that explains all that these are the other people who have been involved with dead bugs besides me me, bars, Adam, Joseph, Anthony, Kahn and maybe you so thank you for your attention there will be a bof after so questions that I haven't answered because I'm out of time and I'd also like to talk about the new package report bits so you guys can see how that works please come at whatever 7 I think it is or something 7 or 8 today and we'll talk about that and have a discussion around table about it too thank you for your attention