[02:04] <wolfger> any KDE user care to confirm Bug 198925 for me?
[02:07] <sectech> Give me a second... I can test this quickly....
[02:11] <sectech_> Did you try shift-delete?
[02:11] <wolfger> no, I did not. Hidden feature?
[02:12] <sectech_> I wouldn't say hidden... It's the same with nautilus in Ubuntu and even in the windows environment
[02:14] <sectech_> There is no "delete" in nautilus either... It's <right-click> and "Move to Trash"
[02:14] <sectech_> brb back to the other machine
[02:14] <wolfger> well, as somebody who's not used Windows or Nautilus in several years, it's hardly obvious ;-)
[02:14] <sectech> k
[02:14] <wolfger> Konqueror used to be the file manager, and "delete" is a right-click option there (albeit disabled by default)
[02:15] <wolfger> so yes, shift-del worked for me
[02:15] <wolfger> thanks!
[02:15] <sectech> no problem.
[04:36] <persia> Anyone have S3 video hardware?  Bug #135344 is very likely still present, but got closed, and would hugely benefit from someone producing a stacktrace.
[04:36] <persia> (rationale for continued existence is that the relevant section of code has not been changed upstream since the bug report was filed)
[04:39]  * greg-g was the one who closed it :(
[04:40] <persia> greg-g: And for good reason.  It's not actionable as is: it really needs someone with that X driver to help hunt down where in the DRi code it is failing.  Further, I hear there ought be a new paradigm for intrepid, which might fix it by accident.
[04:40] <greg-g> heh, fixing by accident, I like that
[04:41] <persia> Happens sometimes for this sort of thing, where there is a crash in the X drivers or in the core libraries.  It's not rare for another application to expose the same issue, and be fixed, with the side effect of closing these bugs (hence the policy on expiring bugs).  Ideally, we'd have enough testers to be able to validate the fixes before the bugs were closed, but we're still short-handed.
[04:42] <greg-g> right right
[04:43] <greg-g> but, your call for testers on that bug is a good idea
[04:43] <persia> This is also an awkward bug, as I wasn't able to reproduce or get enough information from the original reporter: it was only the secondary comment that led to showing a slightly different bug, where there was a chance for fixing it.
[04:43] <greg-g> yeah
[04:44] <persia> Well, for that bug, I'm not sure.  There's lots of reasons torcs can crash on startup.  Likely more useful to get the torcs -d output (after installing the relevant -dbgsym packages) separately for each cause.
[04:45] <persia> For apport bugs, I'm much more inclined to see someone retest, and demonstrate that it is resolved to close them.  Unfortunately, we've yet to establish a means by which apport can generate enough information to create a test-case for retesting.
[04:45] <greg-g> yeah, that would be pretty nice if it could do that
[04:48] <persia> Regarding the call for testers: I'd think this channel would likely be best.  When there's an obvious bug where there's some information, but it's not yet triaged, it's nice to get a second look.  Policies have changed, but back in Breezy, we used to follow a three-strikes rule, where the bug would be shown to be unreproducible for all of i386, amd64, and powerpc before we closed it, with calls for help testing here.
[04:49] <persia> Now there are too many bugs to do that easily, but I still like to ask when I half-understand a bug, but can't replicate it myself.
[04:50] <greg-g> that isn't a bad idea (I wasn't dealing with bugs during breezy, didn't know of that policy)
[04:51] <persia> Depends on the volume.  It was nice to help identify bugs that only affected a single architecture, or only certain hardware.  It also gave a sense of surety: when one person can't replicate a bug, it might be a local configuration.  When several people can't replicate, it's clearly either not present, or incredibly badly described.
[04:56] <greg-g> heh
[05:02] <greg-g> (sorry, I just have nothing to add :) )
[05:15] <bdmurray> greg-g: you've been working on 121279 kind of?
[05:15] <bdmurray> bug 121279
[05:16]  * greg-g looks
[05:17] <greg-g> bdmurray: yeah, trying to coordinate the information between upstream and LP
[05:17] <bdmurray> I stumbled across bug 227585 which is a dup of yours and has a patch
[05:18] <bdmurray> I'm not sure why 121279 is fix committed
[05:18] <greg-g> because the patch was committed in upstream, but not in Ubuntu yet
[05:20] <greg-g> is that the correct status for that situation, fixed in upstream but not in Ubuntu yet?
[05:20] <bdmurray> Doesn't the upstream watch reflect that by being Fix Released?
[05:21] <bdmurray> FC should be used when it is pending an upload or in -proposed
[05:22] <greg-g> I'm checking our version to see if that patch is applied
[05:22] <bdmurray> sweet!
[05:24] <greg-g> patch not applied in our version
[05:25] <bdmurray> What do you want to move the patch to your bug or make yours a dup of the one with the patch?
[05:27] <greg-g> either way is fine with me, probably option A since more people are already "invested" in that one
[05:27] <greg-g> maybe I should learn how to make a debdiff with that patch :)
[05:27] <Oddd> That bug has been a pretty (un)popular one.
[05:27] <bdmurray> Sounds good to me, it might be something we could get into 8.04.1 too
[05:27] <Oddd> IT will be good to have it licked
[05:28] <greg-g> alright, I'll add the patch to 121279
[05:29] <bdmurray> Okay, and I'll take care of getting it on the 8.04.1 radar
[05:30] <greg-g> awesome
[05:33] <bdmurray> okay, all set
[05:35] <greg-g> so fix committed is only for committed in our sources, not upstream correct?
[05:36] <greg-g> (hence my FC being incorrect on that one)
[05:36] <bdmurray> Right, I've heard some other teams are using it a different but I'll find out more at UDS
[05:37] <bdmurray> greg-g: you use greasemonkey right?
[05:37] <greg-g> awesome, thanks
[05:37] <greg-g> yeah
[05:38] <bdmurray> I wrote another script to identify patches
[05:38] <greg-g> ooo
[05:39] <greg-g> bdmurray: may I test it? :)
[05:39] <bdmurray> http://people.ubuntu.com/~brian/greasemonkey/lp_patches.user.js
[05:40] <bdmurray> If you look at bug 121279 you'll see what it does
[05:40] <bdmurray> It flags bugs that have attachments that are checked as being patches
[05:41] <bdmurray> Er flags attachments
[05:41] <bdmurray> Its better if you look at a bug w/ a bunch of attachments
[05:42] <bdmurray> bug 204775 is a good example
[05:42] <greg-g> ahh yeah, the star
[05:42] <greg-g> good deal
[05:43] <greg-g> simple, elegant, not in your face, I like
[05:43] <greg-g> seems like an obvious thing for LP to do honestly though, differentiating between attachments and patchs visually
[05:43] <bdmurray> yep! I've plans to make it show up in the comments too...
[05:44] <greg-g> cool
[05:44] <bdmurray> Or mention it to the lp team
[05:45] <persia> Well, there's bug #172507, which is close
[05:45] <persia> Also bug# #180388
[05:45] <persia> Err bug #180388
[05:45] <persia> Or even bug #4780 :)
[05:46] <bdmurray> I think part of the problem is a lot of things get flagged as a patch incorrectly
[05:47] <persia> Yes, well, that's true.  It's unfortunately hard to distinguish a useful patch from a non-patch.
[05:47] <greg-g> ahh, right
[05:47] <bdmurray> Well, I've seen people mark log files as patches too
[05:48] <persia> I've a few more LP bugs in that cluster listing, but discussion in those and in MLs indicates that it's not safe to use file type, or content, etc.  There's also no good way to mark a patch as good or not good, or any means to describe responses to a patch in a encoded manner.
[05:48] <persia> I've seen people mark screenshots as patches :)
[05:48] <bdmurray> My hope was the gm script would help a bit by drawing your attention to what is a patch
[05:49] <persia> On the other hand, I've received images that were "patches", and applied them to the repositories, so it's hard.
[05:49] <bdmurray> or is flagged as a patch
[05:49] <persia> The GM script is a great step forward.  I think the difficulties have limited LP development, and that lack of good patch tracking creates a larger split between "developers" and "users".
[05:49] <greg-g> well, sleep time, goodnight you two
[05:51] <bdmurray> I'm shocked at how many new bugs have patches
[05:51] <bdmurray> Gah, things flagged as patches
[05:51] <persia> Yeah.  There are a heap of new bugs with real patches, which is a nice thing about open source, but my experience was that only about 20% were real patches.
[05:52] <bdmurray> It'd be nice to get some hard numbers on that
[05:53] <persia> At one point I was using the "patch" tag to identify things I knew were good patches, in the hopes that developers would use that to pull triaged patches and apply them to the repos, but lots of people seemed to think the "patch" flag was sufficient.
[05:53] <persia> Yes it would.  Nobody has yet been willing to review enough of them, and of those that have, the numbers have always been put to question, as the act of reviewing and cleaning them alters the values.
[08:49] <Iulian> G'morning
[09:03] <dsas> brainstorm has died. Can't connect to database.
[09:08] <narcan> https://bugs.launchpad.net/ubuntu/+source/kazehakase/+bug/228918
[13:21] <ssam> has launchpad died?
[13:23] <ssam> hmm maybe its just epiphany :-(
[14:21] <bddebian> Boo
[14:23] <ssam> eeek
[14:24] <bddebian> :)
[14:34] <Iulian> Heya bddebian.
[14:36] <bddebian> Hello Iulian
[14:44] <geser> Hi Iulian, bddebian
[14:45] <bddebian> Hi geser
[15:14] <Iulian> Hey geser
[18:12] <qense> hello
[18:13] <jdavies> hi qense
[18:15] <NiceNerd> Hi guys from what I can tell on google the issue I am having may be a bug but I am not sure
[18:15] <NiceNerd> During install I cant get past splash screen
[18:15] <NiceNerd> it goes to busybox
[18:16] <NiceNerd> and gives me text on ata and other stuff
[18:16] <NiceNerd> and I think it thinks my hard drive is sata and its not
[18:16] <NiceNerd> sda means sata right?
[18:17] <qense> yes
[18:17] <NiceNerd> ok thought so
[18:17] <qense> but other harddisk and even usb sticks can also be considered as sd*
[18:17] <NiceNerd> really
[18:17] <NiceNerd> ok
[18:18] <NiceNerd> hmm I am at a loss then tried 3 different install cds and same thing
[18:21] <qense> :(
[18:21] <qense> what's the exact things that happens after the splash screen stops?
[18:21] <qense> what's the error message you get?
[18:22] <NiceNerd> It goes to busybox
[18:22] <NiceNerd> and starts saying ata3,00 status DRDY
[18:22] <NiceNerd> exception Emask 0x0 SAct....
[18:23] <NiceNerd> cmd c8/00:08:00....
[18:23] <qense> I think that's a bug
[18:23] <NiceNerd> sometimes I get buffer I/O error on device sda, logical block 0
[18:24] <NiceNerd> ok
[18:24] <NiceNerd> anything I can do to get around it?
[18:30] <qense> sorry, was reading something else
[18:31] <qense> I don't know what you could do, since I'm not at your place :)
[18:31] <qense> it's very hard to determine the cause when the computer is not in front of you
[18:32] <NiceNerd> I understand that I am a technician myself I just asked if you knew of any fixes for what I was having a prob with
[18:48] <geser> NiceNerd: do you have any problems with that hard disk?
[18:49] <geser> does Windows have any problems with the hard disk (of course only if Windows is installed)?
[18:50] <NiceNerd> no problems with the hard drive at all
[18:50] <NiceNerd> I am thinking it might be my CDROM
[18:50] <NiceNerd> I am trying something
[20:43] <greg-g> bdmurray: pedro sometimes produces a better stack trace for when I forward bugs upstream to gnome (not sure how he does it, I just copy the traceback from apport).  Is there something else I could do for this bug? http://bugzilla.gnome.org/show_bug.cgi?id=532523
[20:43] <greg-g> bdmurray: just to clarify, he just does it when he sees it forwarded, I don't ask him and he doesn't ask me :)
[20:44] <greg-g> bdmurray: for example, see http://bugzilla.gnome.org/show_bug.cgi?id=528653
[23:56] <noelferreira> my keys sometimes get stucked and other times simply doesn't work. can you help me with this huge bug? http://pastebin.com/m2b2e6e43