[00:29] <BUGabundo> going to bed. bye
[00:29] <Flare183> ok
[00:34] <bcurtiswx> after this im going to quit IRC on Empathy having this channel as my favorite.. when i come back I want to know if i quit or not
[00:34] <bcurtiswx> back... any change?
[00:36] <hggdh> from what?
[00:36] <hggdh> :-)
[00:37] <hggdh> join/part were hidden here. If you want to try again, I have them visible now
[00:38] <Pici> It said you left, not quit.
[00:42] <bcurtiswx> ok, thanks :-)
[00:42] <bcurtiswx> another feature I think people will want in Empathy
[01:10] <djdarkman_> hello, my upgrade from jaunty to karmic broke my webcam(driver), how do I report this bug?
[06:55] <dholbach> good morning
[09:47] <slicer> Hi. Bug 412873 is a duplicate of bug 407848. I have access to the first, but not the latter, so I can't update the status of the bug.
[09:47] <ubot4> slicer: Bug 412873 on http://launchpad.net/bugs/412873 is private
[09:47] <ubot4> slicer: Bug 407848 on http://launchpad.net/bugs/407848 is private
[09:49] <slicer> .. and the log for the one I can see has a log entry that says 'visibility: private -> public', why is ubot4 saying it's private?
[15:16] <kaddi> Hi, I'm trying to collect some info on the intel freezes, but I need some help as the instructions I found are for ubuntu and not kubuntu: https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-freeze-test
[15:17] <kaddi> in step 7 it says to copy sudo cp /var/log/gdm/\:0.log dri_debug/gdm.log, but I have no folder gdm or kdm and the kdm.log in /var/log is over 1Gb.. should I just leave that step out or do you need some specific information from kdm.log?
[15:18] <StoB> kaddi: maybe you could rename your kdm.log, do the steps and attach the new kdm.log?
[15:20] <kaddi> StoB I will do that.. but I mostly get random freezes, I can not provoke freezes on the 2.6.28-14 kernel, so the kdm.log might still get very big
[15:20] <kaddi> which I was planning on reporting
[15:20] <StoB> kaddi: It says "REQUIRES: 2.6.30-rc2 kernel or later." on this page
[15:23] <kaddi> lol, true. Ok, I'll stick to the newer kernel then. Any advice on what would be useful for freezes on the standard jaunty kernel. Anything that would not get collected by ubuntu-bug and should be added in?
[15:23] <StoB> kaddi: I don't know.
[15:25] <kaddi> ok, I'll see what I can do :)
[15:27] <StoB> In a bug report, what does "[SRU]" stand for?
[15:27] <Pici> Stable Release Update
[15:27] <Pici> !sru
[15:27] <ubot4> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
[15:30] <StoB> Pici: Thanks.
[15:32] <StoB> Bug #253465 "[SRU] daemontools-run needs to work with upstart" prevents successful installation of daemontools-run. The problem is known at leasts since June 30th, 2008. What can be done to get it fixed faster?
[15:32] <ubot4> Launchpad bug 253465 in daemontools "[SRU] daemontools-run needs to work with upstart" [Medium,Confirmed] https://launchpad.net/bugs/253465
[15:38] <bddebian> Boo
[15:39] <kaddi> hmm, I'm new to this whole bug reporting thing. I reported a bug against the xserver-xorg-video-intel package yesterday (at least that's what I was trying to do) and I can't find it in the list of bugs affecting it. Do bugs need to be triaged before they are assigned to a package, or did I do something wrong?
[15:41] <virtuald> log in to launchpad and click on your name then bugs
[15:42] <kaddi> yes
[15:42] <thekorn> bddebian, are you ok? 9 minutes from join to the daily 'Boo' is a loong time ;)
[15:42] <kaddi> virtuald the bug is there, it is just not listed in the bugs affecting xserver-xorg-video-intel, which made me wonder if I missed a step somewhere
[15:44] <bddebian> thekorn: No, I'm never OK :)
[15:45] <thekorn> haha, ok, this explains a lot
[15:45] <virtuald> kaddi: you didn't give me/us your link
[15:45] <kaddi> ah sorry, https://bugs.launchpad.net/ubuntu/+bug/415132
[15:46] <ubot4> Launchpad bug 415132 in ubuntu "GM965/GL960 intel freeze with kde desktop effects" [Undecided,New]
[16:08] <StoB> I'm new to the bug reporting process. I have marked several bug reports as duplicates to #253465. Should I add add a message like in https://bugs.launchpad.net/ubuntu/+source/daemontools/+bug/308028/comments/2 to those bug reports?
[16:08] <ubot4> Launchpad bug 308028 in daemontools "package daemontools-run 1:0.76-3 failed to install/upgrade:  (dup-of: 253465)" [Undecided,Confirmed]
[16:08] <ubot4> Launchpad bug 253465 in daemontools "[SRU] daemontools-run needs to work with upstart" [Medium,Confirmed]
[16:16] <hggdh> StoB, yes, you should always add a comment like in 308028. You can review a series of standard replies at https://wiki.ubuntu.com/Bugs/Responses
[16:17] <hggdh> StoB, in fact, https://wiki.ubuntu.com/BugSquad/KnowledgeBase is a good reference to keep
[16:22] <StoB> hggdh: Thank you.
[16:23] <hggdh> StoB, you are welcome. Thank you for helping.
[16:25] <micahg> hggdh: I might be a little late to the meeting
[16:25] <hggdh> micahg, no prob. I will talk -- if needed -- on your entries
[16:26] <micahg> thanks :)
[16:40] <andresmujica1> hi everyone.. 20 mins for Bugsquad meeting (it would be held at this channel)
[17:00] <hggdh> BONG BONG BONG
[17:00] <bdmurray> heh
[17:00]  * grepory dances
[17:00] <hggdh> (this is the bell)
[17:01] <pedro_> hi folks
[17:03]  * andresmujica1 waves
[17:03] <andresmujica1> :)
[17:03] <andresmujica1> ok, let's check what do we got
[17:03] <andresmujica1> https://wiki.ubuntu.com/BugSquad/Meeting
[17:04] <thekorn> hi bugsquad!
[17:06] <andresmujica1> there are some topics proposed and some items in the agenda...
[17:06]  * andresmujica1 waves thekorn
[17:07] <andresmujica1> Triaging versus Bug Fixing/Closing in Karmic  (anyone knows more about this topic?  i don't recall whom proposed it)
[17:07] <bdmurray> Nor do I
[17:07] <pedro_> well.. that's something we talked about UDS with the desktop team
[17:08] <pedro_> they're going to spend more time doing bug fixing rather than triaging for the current cycle
[17:08] <pedro_> but i don't know who added that to the bugsquad meeting agenda, probably got confused by the title
[17:09] <hggdh> so, if I understand it right, the desktop team will need more help on triaging
[17:09] <pedro_> as always, yes ;-)
[17:10] <andresmujica1> something that concerns me is that the biggest triaging effort is mostly done by the devs themselves...   how can we help them more?
[17:10] <bdmurray> I think trying to recreate bugs, documenting test cases, and forwarding upstream are all a big help.
[17:13] <andresmujica1> ok... so ?
[17:13] <matti> :)
[17:13] <bdmurray> I think we should move to the next item since there doesn't seem to be much to discuss here
[17:14] <andresmujica1> ok. in the proposed topics we've got
[17:14] <andresmujica1> Tasks to do for the team
[17:15] <andresmujica1> from previous meetings we've discussed some ideas,
[17:15] <andresmujica1> the bug triaging classroom session for the Global Ubuntu Jam, we're looking for someone that can give the session.
[17:16] <andresmujica1> and the wiki page with the most important bugs per cycle
[17:16] <bdmurray> At one point in time we had a todo list at https://wiki.ubuntu.com/BugSquad/TODO
[17:16] <bdmurray> Perhaps we should revive that?
[17:17] <hggdh> sounds like a good idea
[17:17] <andresmujica1> yeap, definitely.
[17:17] <pedro_> yeap, would be good for keeping track of the tasks
[17:18] <pedro_> to know who is doing what
[17:18] <bdmurray> However, people have to actively monitor the wiki page
[17:18] <hggdh> which, I guess, comes smack on -control duties
[17:18] <bdmurray> Maybe sending monthly reminders of what's on it would be good?
[17:18] <andresmujica1> we can subscribe to the page
[17:19] <hggdh> also, but the reminders help
[17:19]  * hggdh had already forgotten about this page
[17:19] <pedro_> perhaps with the bugsquad meeting report? ;-)
[17:20] <andresmujica1> ok, i'm offering to update the TODO list with the tasks that have been talked within this meetings,  and yes, it can be sen with the report too
[17:20] <andresmujica1> sent
[17:20] <pedro_> person: No such object "https://bugs.edge.launchpad.net/~pvillavi". <- grgr love you lp
[17:21] <andresmujica1> ok.
[17:21] <andresmujica1> now:  New bug-stuff to look forward to -- bcurtiswx
[17:21] <andresmujica1> not here...
[17:21] <andresmujica1> i was wondering about package-hooks , where can i find a list of the ones that are being worked on ??
[17:22] <bdmurray> andresmujica1: what do you mean by being worked on?
[17:22] <andresmujica1> there's a TAG or someting at LP ?
[17:22] <bdmurray> The only one I know of being worked on is evolution atm
[17:22] <andresmujica1> i mean, i want to make an apport-hook but if someone already is working on it it would be better to find a different one..
[17:23] <bdmurray> I don't think that many people are working on them, so I'd just have at it
[17:23] <andresmujica1> ok. the standard procedure is to make the bug report and ping piti, right?
[17:24] <bdmurray> ping me actually
[17:24] <andresmujica1> ok
[17:25] <bdmurray> I'll chase getting them incorporated / uploaded
[17:26] <pedro_> that reminds me that i need to open some bug reports about the ones i wrote during the sprint
[17:26] <bdmurray> pedro_: yes, that'd be great!
[17:27] <andresmujica1> Policy of what to do when bugsquad members need help but don't ask -- micahg
[17:28] <hggdh> and -- more importantly -- do not follow the rules
[17:29] <pedro_> send them an email explaining why what they did is wrong? include a link to our documentation and offering help if they have a question?
[17:29] <bdmurray> One issue here might be that the Bug Squad is an open team so there is no commitment to follow the rules
[17:29] <andresmujica1> They aren't using stock responses (and the replies aren't even close)
[17:29] <andresmujica1> Changing status with no reply
[17:29] <andresmujica1> Reply without specifying next step (i.e. what the reporter needs to do)
[17:29] <pedro_> i tend to do that most of the times
[17:30] <hggdh> heh
[17:30] <pedro_> " Changing status with no reply" < - i hate this
[17:30] <bdmurray> I try to do what pedro recommends
[17:30] <pedro_> everytime you do that, a kitten die
[17:31] <hggdh> OMG, we are running out of kittens!
[17:31] <bdmurray> That's what I added the contact user hyperlink into lp_karma_suffix
[17:31] <bdmurray> The idea being you'd see something inappropriate and contact them directly
[17:31] <bdmurray> However, I think it is important to verify that the person is in fact a member of bug squad
[17:32] <hggdh> so. I suggest -control starts contacting -- in a nice way -- the -squad member that are doing that, as we find them
[17:32] <hggdh> s/member/&s/
[17:32] <andresmujica1> what happened with the discussion about making bug squad a closed team, with some minimal requirements to join?
[17:33] <bdmurray> That needs to be discussed on the mailing list, particularly what to do with existing members
[17:33] <bdmurray> Do we just wipe out the team and start over or ...?
[17:34] <hggdh> best would be to keep on with the existing members, and add an expiry
[17:34] <hggdh> and request an acceptance of the (new) rules
[17:34] <andresmujica1> if you don't touch a bug for 3 months set a 30 days expiration ..
[17:34] <pedro_> andresmujica1, that'd be tricky to do
[17:35] <bdmurray> Adding an expiration for all members would be easy though
[17:35] <hggdh> of course, this will also add on overhead for the bug-meisters
[17:35] <hggdh> since only them (looking at Brian, directly) can do it
[17:35] <bdmurray> hggdh: for managing the team?  I've written some launchpadlib scripts for managing teams so its not so bad
[17:36] <bdmurray> Way better than it used to be!
[17:36]  * hggdh retracts the observation ;-)
[17:36] <pedro_> There are 2046 direct members of the "Ubuntu BugSquad" team <- wow
[17:36] <andresmujica1> how many bugsquad members are actively triaging ?  is it possible to now?
[17:37] <bdmurray> andresmujica1: yes, but its somewhat hard
[17:37] <hggdh> So. We intend to make -squad closed; -sqaud member should follow the rules, including subscribing to the ML
[17:38] <andresmujica1> i would agree with that.  Even with a general expiration after some ML messages explaining why...
[17:38] <bdmurray> and what it means to be a member of the bugsquad
[17:39] <hggdh> +1
[17:39] <pedro_> I'm agreed with that
[17:40] <hggdh> any other vote? Otherwise we are agreed, and move on
[17:41] <andresmujica1> ok
[17:41] <andresmujica1> so
[17:41] <andresmujica1> Mentoring BugSquad members -- related to bug 414627 (malone) -- micahg
[17:41] <ubot4> Launchpad bug 414627 in malone "allow users to select another user to follow/watch" [Undecided,Incomplete] https://launchpad.net/bugs/414627
[17:41] <micahg> so, I was thinking to make mentoring a more official feature of bug control
[17:41] <hggdh> this is something MIcah and I discussed: would help a lot on following new -squads, or proposed -controls
[17:41] <pedro_> I'd *love* to have that on launchpad, it helps quite a lot on Gnome Bugzilla
[17:42] <micahg> yeah, that feature would be nice
[17:42] <pedro_> and would be perfect for the mentoring program we're trying to build
[17:42] <hggdh> pedro_, exactly the same point I raised with Micah
[17:42] <micahg> but I realized that it's possible to a point right now
[17:42] <micahg> if you're subscribed to the package in questions, you can filter by commentor
[17:42] <bdmurray> It's not big brother-ish?
[17:42] <micahg> bdmurray: maybe it should be limited to admins
[17:42] <hggdh> bdmurray, it may deteriorate to BB, without control
[17:42] <micahg> and no, there's nothing private about non-private bugs are there?
[17:43] <bdmurray> It implies that I don't trust you and need to watch your every move
[17:43] <hggdh> it does. This is the point
[17:43] <micahg> bdmurray: well, not trust is different than training I woudl think
[17:44] <micahg> why is this different than a seasonsed person standing over another while training?
[17:44] <andresmujica1> hmm, i'd see it the other way around.. i want to follow the example from someone else...so i watch how he's doing it
[17:44] <micahg> and the person should know that you're watching I would think
[17:44] <hggdh> we need to verify. Andre did that with me, for example, when I started in Gnome. I see no problems, since all bugs are viewwable by anyone
[17:44] <micahg> andresmujica1: I think both ar egoof
[17:44] <micahg> *good
[17:45] <hggdh> it is similar to anyone proposing to MOTU, for example (but without the help of 'following'
[17:46] <micahg> anyway, you can kind of do it now if you subscribe to all bug mail and filter by commenter
[17:46] <hggdh> and accept thousands of email per day, of course
[17:46] <micahg> but this would make it so that you can do it more easily
[17:47] <hggdh> question is: what incentives are there to become a bugsquad?
[17:48] <hggdh> (since I can comment on any bug, anyway)
[17:48] <micahg> only to say that they're dedicating themselves to helping
[17:48] <bdmurray> hugs?
[17:48] <micahg> but I see where you're going hggdh
[17:49] <hggdh> perhaps as a pre-req to become a -control?
[17:49] <micahg> bugsquad should get more help from -control
[17:49] <micahg> that's how I learned
[17:50] <hggdh> yes, and this is the mentoring we are trying to start
[17:50] <micahg> and it encouraged me to keep going
[17:51] <andresmujica1> ok, we've got a few minutes, so let's wrap up ...
[17:51] <micahg> maybe we should resurrect the wiki page for mentoring
[17:51] <hggdh> and start the official mentoring soon
[17:51]  * hggdh pokes pedro_ ;-)
[17:52] <pedro_> hggdh, just waiting for the response from charlie-tca, if he doesn't answer at the end of this week we might look for someone else to fit there
[17:52] <pedro_> we cannot wait forever
[17:53] <pedro_> micahg, there's a plan for starting a more structured mentoring program: https://wiki.ubuntu.com/QATeam/Specs/SpecialisationWithinBugcontrol
[17:53]  * micahg is looking
[17:54] <pedro_> would be really good if everybody could look at the spec and add comments about it
[17:54] <micahg> on the comment page
[17:54] <micahg> ?
[17:54] <micahg> I don't see a comment page
[17:54] <pedro_> micahg, feel free to add those at the bottom
[17:54] <hggdh> just add a Comment header, and we will go from there
[17:55] <micahg> +1 on the idea
[17:55]  * micahg is already specialized :)
[17:56] <andresmujica1> ok, let's go to Open Discussion  and let the adopting package topic for the next meeting
[17:56] <micahg> would comments per category be better?
[17:56] <bdmurray> wrt to adopting packges I have a question
[17:57] <bdmurray> Would it be interesting to know what packages nobody is subscribed to?
[17:57] <pedro_> a big yes ;-)
[17:57] <micahg> bdmurray: my guess would be most
[17:57] <micahg> unless people are subscribed to -bugs
[17:58] <micahg> or maybe not...
[17:58] <andresmujica1> hmm.. sure.  even get in touch with main developer and help him subscribe to its package...
[17:58] <hggdh> micahg, I think commenting at the bottom is better -- all comments together
[17:58] <micahg> ok
[17:58] <bdmurray> micahg: but if you knew netcat had nobody subscribed to its bug reports and it only has <5 open bugs might that help you choose a package to adopt?
[17:59] <micahg> yeah, that's a good point
[17:59] <micahg> maybe both stats together would be good
[17:59] <bdmurray> and that it is synced with debian so valid bugs should be forwarded upstream ...
[17:59] <hggdh> I think it would -- I would not be afraid of being overwhelmed, and this plays a role
[18:00] <micahg> the question is how do we cover 20k pkgs with 125 people?
[18:00] <hggdh> we do not. There is only so much we can do. But we *can* start
[18:00] <bdmurray> exactly
[18:00] <micahg> ok, makes sense
[18:01] <hggdh> and it will be better than *not* doing anything
[18:01] <micahg> my plan has always been adopt a package, get the bugs under control, then adopt another
[18:01]  * micahg is still working on the first bunch :)
[18:01] <hggdh> its a good plan :-)
[18:02] <hggdh> well, you started with FFox, what did you expect LOL
[18:02] <micahg> when I started, there were only 1600 FF bugs, now there are 2k :(
[18:03] <hggdh> one thing we might try is to have more than one for large (in terms of bugs) packages
[18:03] <hggdh> if we can get it for these large packages, it is already a victory
[18:03] <micahg> well, that's where mentorhelp
[18:03] <hggdh> yes
[18:04] <micahg> you get 2-3 people training on bugs in a large package
[18:05] <hggdh> So. Comments are needed on https://wiki.ubuntu.com/QATeam/Specs/SpecialisationWithinBugcontrol
[18:05] <hggdh> the sooner, methinks, the better
[18:05]  * micahg will comment tonight
[18:05] <hggdh> andresmujica1, back to you ;-)
[18:06] <andresmujica1> ok, about the upcoming Developer week, anything we can help on?
[18:08] <hggdh> bdmurray, pedro_ ?
[18:08] <bdmurray> I'm all set thanks for asking
[18:10] <pedro_> well, just help on welcoming the new people (if there's any) after the talk here at the channel
[18:10] <hggdh> ROLF
[18:11] <andresmujica1> ok, anything else we should discuss after closing ?
[18:12] <bdmurray> andresmujica1: you'll send out minutes correct?
[18:12] <andresmujica1> yeap
[18:12] <andresmujica1> starting right now.
[18:12] <bdmurray> and the next meeting will be on 8 September?
[18:13] <andresmujica1> if everyone agrees, it would be Sept 8th
[18:13] <micahg> +1
[18:13] <andresmujica1> same hour same channel?
[18:13] <pedro_> sure
[18:13] <bdmurray> that sounds good to me
[18:14] <andresmujica1> ok, thanks everyone :)
[18:14] <pedro_> thanks!
[18:15] <bdmurray> thanks!
[18:15] <hggdh> thank you, andresmujica1
[18:15] <micahg> thanks andresmujica1
[18:17] <bdmurray> by the way does lists.ubuntu.com crash firefox for anyone else?
[18:17] <micahg> which version?
[18:17] <micahg> wfm in 3.5
[18:17] <bdmurray> 3.5 it also crashed epiphany for me
[18:19] <hggdh> did not crash here, on FF 3.5
[18:21] <bdmurray> hrm, must be me
[18:26] <micahg> bdmurray: karmic?
[18:26] <bdmurray> micahg: of course!
[18:27] <micahg> ah, others have been reporting crashes as well
[18:28] <micahg> can you get a good backtrace and open a bug, there's about 20 crash reports I still have to look at
[18:30] <bdmurray> micahg: I'll see what I can do
[18:32] <kklimonda> micahg: it's not really that uncommon to see a crash of the Firefox :)
[18:32] <micahg> kklimonda: it's probably not firefox :)
[18:33] <micahg> most of the crashes are GTK related in karmic from what I've seen
[18:36] <kklimonda> damn, I hate crashes I can't reproduce when I have time and that hit me when I don't expect them..
[18:37] <kklimonda> anyone else having problems with gpm? It just crashes (and brings down whole session with it) when I unplug a usb mouse..
[18:37] <kklimonda> (gnome-power-manager)
[18:37] <chrisccoulson> g-p-m crashing won't bring down the whole session. that must be something else
[18:38] <kklimonda> chrisccoulson: I know it shouldn't :/
[18:38] <kklimonda> chrisccoulson: apport has marked my two reports as duplicates of bug 394700
[18:38] <ubot4> Launchpad bug 394700 in gnome-power-manager "gnome-power-manager crashed on removing the battery" [Medium,Confirmed] https://launchpad.net/bugs/394700
[18:40] <kklimonda> chrisccoulson: is it even possible that removing usb mouse could make it crash?
[18:42] <bdmurray> micahg: I updated and its fine now
[18:42] <micahg> cool, there was a new version that fixed a lot of the GTK crashes
[18:45] <chrisccoulson> kklimonda - possibly, i'm not sure though. it's not really clear whats happening from that backtrace
[18:47] <kklimonda> heh, I'll try to reproduce it and get more info next sunday
[18:48] <mac_v> bdmurray: could you pls update the lp responses ?
[18:50] <bdmurray> mac_v: could you elaborate a bit?
[18:51] <ogra> add some smileys :)
[18:52] <mac_v> bdmurray: the lp repsonses  > https://wiki.ubuntu.com/Bugs/Responses  , i added 1 for the papercuts
[18:52] <bdmurray> that's what launchpad should support - emoticons!
[18:52] <mac_v> +1 for that :)
[18:52] <bdmurray> mac_v: you'd like that added to the greasemonkey script / firefox extension?
[18:53] <mac_v> bdmurray: yeah...  sorry i didnt properly elaborate>faceplam<
[18:55] <bdmurray> mac_v: I'll try and it get to it.  A patch would speed up the process though.
[18:55] <mac_v> bdmurray: hmm... not very sure how to do that :(
[18:55] <bdmurray> the xml file is at http://people.canonical.com/~brian/greasemonkey/bugsquad-replies.xml
[18:56] <micahg> mac_v: all the common ones were in there.  I added a few custom ones of my own that are Firefox specific
[18:56] <mac_v> oh... ok
[18:56] <micahg> I think
[19:06] <mac_v> bdmurray: http://dl.getdropbox.com/u/1325768/bugsquad-replies.xml , added to the end... line 254 onwards , also added another one about sending the report upstream. could you check it?
[19:06] <mac_v> micahg: how do i reorder the replies?
[19:11] <kklimonda> mac_v: the one about sending report upstream isn't generic - sholdn't link be https://wiki.ubuntu.com/Bugs/Upstream ?
[19:13] <mac_v> kklimonda: oh... yeah... i was thinking only about gnome!
[19:13] <mac_v> editing
[19:14] <mac_v> new version http://dl.getdropbox.com/u/1325768/bugsquad-replies.xml
[19:16] <mac_v> kklimonda: once reloaded . where do these get saved in the system? i'm not able to find the file.
[19:17] <kklimonda> mac_v: I think it lands in firefox preferences
[19:17] <kklimonda> prefs.js
[19:17] <mac_v> kklimonda: /usr/share/firefox-lp-improvements has the scripts but , but the responses! i'm stumped
[19:17] <mac_v> oh
[19:18] <micahg> mac_v: check about:config
[19:20] <mac_v> hmm... i just have to reorder the numbers , nice :)
[19:22] <bdmurray> I'm not sure what will happen after they get updated again though
[19:23] <mac_v> bdmurray:  i have not rearranged them waiting for you  :)
[19:24] <mac_v> do they auto update or only manual reload?
[19:25] <bdmurray> they check for updates every 48 hours I think or you can manually force a reload
[19:33] <mac_v> ok
[19:37] <bdmurray> mac_v: I've made some changes to what you had.  You can see what I have at http://pastebin.osuosl.org/28226
[19:39] <mac_v> bdmurray: pls dont change the papercut response , that response was how the design team wanted it
[19:40] <mac_v> i added the response to the wiki only after suggestions from mpt.
[20:07] <bdmurray> mac_v: well, I thought the grammar could be a bit more verbose and punctuated differently.
[20:10] <greg-g> "pls" -> "please" is a good thing, right? :)
[20:11] <bdmurray> Yes, its not a txt message
[20:14] <mac_v> bdmurray: oh , the "please" and the "information" can be full , thats not the problem , they didnt want to use "Unfortunately" and the line order
[20:16] <mac_v> bdmurray: i had a template with unfortunately , and a bit different... they tweaked it ... dont ask me why ;)
[20:16] <mac_v> cause i dont know
[20:17] <bdmurray> mac_v: okay, how about http://pastebin.osuosl.org/28241
[20:19] <mac_v> bdmurray: is only "for" ? correct , shouldnt it be only "in" project... rest is fine
[20:20] <mac_v> last line
[20:21] <bdmurray> okay, in it is
[20:21] <mac_v> :)
[20:28] <mac_v> i'm just a messenger
[21:04] <micahg> pedro_: that subscribe bug in lp is bug 415166
[21:04] <ubot4> Launchpad bug 415166 in malone "Launchpad says I don't exist when I subscribe to a bug" [High,Fix committed] https://launchpad.net/bugs/415166
[21:05] <pedro_> micahg,  yeap, thanks
[23:09] <micahg> how often does apport retrace?  can I set something to retrace?
[23:09] <bdmurray> that should be handled automatically, what are you looking at?
[23:09] <micahg> I just got notified that 4 ff3.5 bugs were retraced
[23:10] <micahg> I was wondering if there's something that I shouldn't do to make sure they are retraced or what?
[23:11] <bdmurray> I believe they are initially tagged needs-retracing so just don't remove that tag
[23:11] <micahg> ok, but if I change the status of the bug, will that affect the retracing?
[23:12] <bdmurray> let me look at the code
[23:15] <micahg> hmm, I think they were private to apport before this
[23:15] <micahg> they were not the ones I was thinking of
[23:16] <bdmurray> the retracer just searches for the tag
[23:16] <micahg> ok
[23:16] <micahg> do we have policies on duping crash reports?
[23:16] <micahg> or is it not possible to create such a thing
[23:16] <bdmurray> the retracer usually handles duplicating of crash reports on its own
[23:17] <micahg> ok, but aren't those only exact duplicates?
[23:18] <bdmurray> yes, that is true
[23:19] <micahg> ok, do we have policies what to do next?  How many of the functions in the backtrace need to match to be a dup?
[23:21] <bdmurray> I don't have a good answer for that, you might check with seb128 or asac
[23:24] <asac> micahg: thats a difficult question
[23:24] <asac> you cannot say for sure without looking at the code in question
[23:24] <asac> if the code looks like it can be triggered through different paths then even a single matchin line might be enough
[23:25] <micahg> ok, so as a matter of policy, what can I do with crash reports?
[23:25] <asac> if the code relies on something really high up in the stack, then everything can be the same. just with different variables etc.
[23:25] <asac> and it can be a different bug
[23:26] <asac> micahg: as a rule of thumb, if the stacktrace is identical you can assume its a dupe ;)
[23:26] <micahg> asac: if the stacktrace is identical, woudlnt' apport dupe it?
[23:26] <asac> in most cases
[23:26] <asac> but apport doesnt do that if there is any ?? in it afaik
[23:26] <asac> (but i might be outdated)
[23:27] <micahg> bdmurray: ^^
[23:28] <bdmurray> right
[23:29] <bdmurray> so apport does the right thing the majority of the time
[23:29] <micahg> ok, so I can look through and if I see ?? and the rest matches, I can dupe it?
[23:30] <hggdh> micahg, probably.
[23:31] <hggdh> the ?? would probably match a line in the fully-resolved bt
[23:31] <hggdh> if the rest matches, then the ?? is probably this one line, and it is almost certainly a dupe
[23:34] <micahg> ok
[23:35] <hggdh> if in doubt, post here the links to both stacktraces, and we will go together looking at it
[23:35] <micahg> :) thankg hggdh
[23:35] <micahg> *thanks
[23:36] <hggdh> welcome
[23:48] <BUGabundo> hello
[23:50] <hggdh> yello, BUGabundo
[23:50] <BUGabundo> hey hggdh