[02:56] about 20 bug reports from that spammer today... [04:17] can somebody change 276530 to medium priority as it *is* actually a security issue. [04:17] ? [04:17] err, not priority, but importance. [04:39] bug 276530 [04:39] Launchpad bug 276530 in gstm "gaskpass does not grab focus" [Low,New] https://launchpad.net/bugs/276530 [04:40] Ryan52: looking [04:40] Ryan52: did you reproduce the bug ? [04:42] no, but two people claim it is a bug, and I don't see any grabbing code in the source, so...ya. [04:42] I haven't tried, either. :P [04:43] ok, set as triaged/medium [04:43] oh. I meant to set it's status to "In Progess". *does that now* [04:44] thanks. === teKnofreak is now known as techno_freak [06:32] Hello. [06:33] Hey jander99 [06:33] I was wondering, does anyone know why Launchpad shows so many open bugs that are sometimes years old? [06:33] It shows all the bugs that were opened, and not closed. [06:34] Some of those should have been closed, but many are still present, and waiting to be fixed. [06:35] It could just be me, but seeing 48000 open bugs is a little daunting when trying to search for one specific to any issues I might have. [06:36] jander99, Understandable, on the other hand, isn't it better to list all the things that are known bugs, so people can fix them, rather than hiding them? [06:37] persia, please don't misunderstand me, but is there not some way maybe the community can help "clean up" the list? [06:38] jander99, Yep. There are three or four ways. [06:38] First, is to go through the bugs, look for duplicates, help make sure they have enough information to understand, etc. [06:39] Second is to test the bugs: start with the version against which the bug is known to have applied, and test again with the current version (if it's different). [06:40] If you can reproduce the bug in the old version, but not in the new version, look through the changelogs, and make "Fix Released" while trying to document which version fixes it. [06:40] Third is to dig into the bugs, understand exactly what is wrong, and make sure that this information is widely distributed. [06:40] This might mean also testing against Debian, and reporting to Debian (and linking the bug) if present in Debian. [06:41] It might also mean testing the newest version or not-yet-released snapshot from the developers, and reporting the bug to the development site if present in the development version. [06:41] (and linking it to the current bug). [06:41] Fourth is to try to prepare a patch for the bug, and get it into the repositories. [06:43] jander99, And anyone is welcome to help with any of those :) We've a bunch of people who do most of this, called "The Bug Squad". You can find links to lots of information about this team in the /topic for this channel. [06:43] Feel free to jump in, and if you've any questions, this is the place to ask. [06:45] persia, thanks. my expertise is in web development, not so much with compiled languages. I wouldn't mind spending some time trying to search for duplicates and just generally clean out some cruft. I would assume launchpad is a moderated system, in that making changes to the status of a bug has to be approved? [06:45] Well, there's no approval or moderation process. Certain features do have ACLs. [06:45] But for Ubuntu bugs, anyone is able to adjust status, except to certain reserved statuses. [06:49] persia, thanks, alot of good information. But looking for bugs has now side tracked me to filling out a feature request or launchpad, ha. [06:52] heh. Happens to many of us :) [06:56] persia, when sorting by "oldest first" it seems to be oldest by submit-date. If that's correct, would the ability to sort by last update be useful? [06:57] * persia thought that was already possible [06:57] I'm trying to find out if it is or not before I submit a blueprint. [06:58] I wouldn't recommend submitting blueprints against LP. [06:58] Better to file bugs. [06:58] Anyway, "least recently changed" and "most recently changed" are probably what you want (and present for me at https://launchpad.net/ubuntu/+bugs) [06:59] jander99, Anyway, to expand on my previous comment, there are three classes of things tracked by launchpad: "answers", "bugs", and "blueprints". [06:59] persia, ah ha, great. saves me time. [07:00] "answers" are best used when someone isn't sure about something, or needs help getting something done. Sometimes these are bugs, and sometimes they are just support requests. [07:00] "bugs" are best used when someone is sure there is a problem "it crashed, this should be like that, etc.". This is used by people discovering things, people doing things, and people requesting things. [07:01] "blueprints" is best used to describe something one is doing as an individual or a team. [07:01] A blueprint might fix several bugs, or it might be unrelated to bugs. [07:02] persia, okay I see. so in my case, had there not been a sorting option, better to say its a bug in the available sorting feature rather than suggesting its a completely new feature [07:02] There's a couple thousand blueprints registered against Ubuntu because people wanted some feature, but as they didn't actually have any plans to implement it, it gets messy, and hard to use for much. [07:03] jander99, Right. Or use a bug to request a completely new feature. It would be a "Wishlist" bug. If it's small, someone can just fix it. If it's big, someone might use a blueprint to track the discussion better. [07:03] persia, indeed. I've been working on a blueprint for better hardware submission for the better part of a year, I actually wrote up an entry on brainstorn but I wasn't very precise. [07:04] "better hardware submission"? You mean hwdb-type stuff? [07:05] persia, yes, something more smolt-like. [07:06] persia, so far its more of a "grand idea" in my head to help unite alot of different distributions together using Smolt so the kernel folks can see what needs more TLC in drivers and such. [07:08] jander99, Ah. That's a bigger project :) Good luck with it. [07:08] Clear descriptions, and building an implementation team are usually the core parts to make a spec successful. [07:09] persia, well, once i have a better thought out idea I'm sure I'll be lobbying in a few #ubuntu channels and probably the #fedora channel too. Believe me, I get all kinds of crazy ideas, but no time to become too impassioned with them right now. [07:14] persia, thanks for your time. I hope to soon have some more time to devote to contributing to Ubuntu. === doko_ is now known as doko [11:34] hey this is for a friend of mine...in windows..how will u detect the motherboard no... i mean somthin like D945GCL === hubuntu is now known as huayra [13:51] i have a problem with virtualbox in jaunty, befor open a bug i want are sure that are bug and no my error [13:51] anyone can listen me? [13:58] Xan3, What's the problem? [13:58] ok, thz [14:00] so. if i try to start vm with virtualbox i recive a error that tell to me that i need to do "sudo /etc/init.d/vboxdrv setup" in console [14:00] but in jaunty /etc/init.d/vboxdrv doesent exists [14:04] Xan3, Yep. Looks like a bug. I'd say it was part of an incomplete fix to bug #293109 [14:04] Launchpad bug 293109 in virtualbox-ose "Purging virtualbox-ose after installation of virtualbox-2.0 fails: update-rc.d: /etc/init.d/vboxdrv exists during rc.d purge" [Medium,Fix released] https://launchpad.net/bugs/293109 [14:04] I'd suggest opening a new bug about this. [14:05] Thanks for testing jaunty so early in the cycle to catch things like this. [14:06] i have saw that page but they are "fix releases" [14:06] so i open new bug? [14:06] Right. [14:07] ok thzzzz [14:07] That bug is fixed, but the fix seems to have triggered this new bug, which sounds like a combination of things: one that it's not starting by default, and another that the error message produced is almost certainly wrong. [14:07] ok [14:07] It's probably worth mentioning 293109 in your new bug report, as why the bug isn't that the file doesn't exist, but rather that the error message is unhelpful, and that the program isn't starting. [14:12] "but rather that the error message is unhelpful" ? [14:17] RIght. The fact that the file isn't there is clearly intentional. [14:17] The error message you are getting is completely useless. [14:30] persia but doesent works.... [14:35] That would be the part about "not starting by default". I do hope it's in the bug report. === mrooney1 is now known as mrooney [17:18] I need some help guys, are there any packages taht need some espesially heavy triaging? [17:19] I'm trying to put out a plan for Hugday for december, get things organized a bit more than just randomwly choosing packages :) [17:22] Awsoonn, You could have an apport day. [17:23] Track down apport crashes: find those with failed traces, and get them closed. [17:23] persia: right on, I'll add that one to the list, :) [17:23] Find those with good traces, and do a code-inspection for a text description of the bug. [17:24] Awsoonn, Another interesting target might be ubuntu-local packages: find all the packages in Ubuntu and not in Debian, and chase those bugs. [17:25] *nods* [17:26] There also seem to still be 122 bugs targeted at feisty. These probably need review: either to be retargeted or to be verified as closeable. [17:28] Another idea would be to do a day for patch integration: there's lots of bugs with patches out there. Perhaps have a day where a couple people offer a quick -classroom session on testing/applying/requesting upload for patches every 4-6 hours, and people chase the list of bugs with the patch flag set. [17:28] I really like that Idea! that would probably get some more turnout since people would get to learn asomethign new out of the deal [17:29] * Awsoonn writes that down [17:29] Just need 4-6 people to run the test/apply/upload sessions, and to work with the -classroom crew on scheduling. [17:29] Something else we used to do for fun was keyword bugdays. [17:29] One of my favorite was "time". [17:29] Basically, pick a word, and do a bugsearch with the word. Find one with about the right number of bugs. [17:30] Then you try to get all those bugs processed. [17:30] :) I've never even thougth about that, we coudl have soem fun there [17:30] I knwe I wouldnt regret asking in #bugs for some help :) [17:32] Hrm. "time" was fun then, but now it gets 8432 results. I'm guessing you want somwhere in the 300-500 range for a good bugday. [17:32] heh, I try to keep it under 200 usually [17:33] turnout isn't quite as strong as it once was :( [17:33] That small? [17:33] Hrm. Defintely needs something to get it interesting. [17:33] normal day include 4-5 people touching a handful of bugs [17:33] "Days of the week" might be an interesting theme. [17:33] How are you tracking this? [17:34] https://wiki.ubuntu.com/UbuntuBugDay/Planning [17:34] Bugsquad throughput seems to run 2500-3000 bugs weekly. [17:34] feel free to add anythign you think of [17:34] If you're only getting a claimed "4-5" people chasing bugs, I think something isn't right about how you are keeping track. [17:36] Oh. Yeah. All the recent ones have been boring. No wonder you get so little official turnout. [17:36] lots of people chasing a package often isn't fun. [17:36] Also, there doesn't seem to be a lot of differentiation from other days. [17:37] So there's no incentive to work on stuff that day as opposed to any other. [17:37] They also seem remarkably frequent. [17:37] When it's once or twice a month, people might schedule their time around it. [17:38] When it's once or twice a week, it's hard to explain why those days are better than others for bugwork. [17:38] that's an otption too [17:39] I've got to take off here, but please do add your ideas, or mail me with some more thoughts [dereck@gmail.com], Thanks persia! [17:40] Awsoonn, That's enough for now :) === RAOF_ is now known as RAOF [21:45] bug 17601 [21:45] Launchpad bug 17601 in xterm "[xterm] add better charclass map" [Wishlist,Fix released] https://launchpad.net/bugs/17601