[00:02] bdmurray, hi :D I see that a lot of bugs that require packaging have broken upstream links so should they be marked invalid or incomplete, which is better in this case [00:03] dhillon-v10: incomplete asking the reporter for working links [00:05] bdmurray, thanks :D you are awesome [00:11] bdmurray: is a bzr checkout the only way to play with search-bugs right now? === malev_ is now known as malev === asac_ is now known as asac === astechgeek is now known as techgeek [05:48] secret!!! [05:48] absolutely no telling === rackIT is now known as rackIT_AFK [06:25] chih: ?? [06:26] micahg, sorry. i was posting on the wrong channel :) [06:26] ok [06:47] micahg: ping, aroudn? [06:47] nigel_nb: yep :) [06:47] been long since I triaged, but I guess today's also lost to work [06:47] anyways, any idea who's responsible for Ubuntu QA blog? [06:48] nigel_nb: pedro I think [06:48] micahg: a little bit of spam which should be removed http://blog.qa.ubuntu.com/node/28 [06:49] its kinda crazy for the QA team website to get spammed, bad publicity [06:49] nigel_nb: it's a blog, if you want comments, you can't avoid it [06:49] micahg: true, but I thought I could alert someone to remove it :) [06:50] of course :) [06:51] do notify pedro if u catch up to speed with him, [06:51] ok === Adri2000_ is now known as Adri2000 [09:57] hi, can someone help me out. I'm trying to get a bugreport for nspluginviewer in konqueror and I can't find the developer packages for it to create a trace === yofel_ is now known as yofel === rackIT is now known as rackIT_AFK [15:09] Boo [15:10] hi bddebian [15:11] Heya thekorn [16:07] hi [16:07] i wanted to report a bug in the karmic binary of gedit, but i don't find the right package where to report [16:07] i only find the source package [16:08] https://bugs.launchpad.net/ubuntu/+source/gedit [16:08] is this the right place to report problems with the binary? [16:10] yes indeed [16:10] the "source" did confuse me [16:10] PrototypeX29A: the source package is the 'mother' of the binary, it's where it's compiled from. [16:10] naturally :) [16:10] several binaries can be compiled from one source package, that's why we distinguish between them [16:11] thanks [16:11] you're welcome :) === mac_v is now known as _vish [16:25] lp #499889 it is [16:25] Launchpad bug 499889 in gedit ""Type name of new folder" does not have focus, when doing "save as" with descending ordering." [Undecided,New] https://launchpad.net/bugs/499889 [17:09] hello, I have a question about triaging a bug. [17:09] specifically 485212 [17:09] if the reporter seems to no longer care, but someone else has marked that it effects them, should I close the report? [17:10] it seems to be a duplicate of 292051 === _vish is now known as \vish [17:12] maybe this falls under can not reproduce [17:12] oder to few information [17:12] szim90: I would mark it a duplicate and add an ubuntu task to the upstream bug [17:14] szim90: actually maybe don't do that... [17:14] hggdh: you around? [17:15] micahg, can I mark an upstream bug if I'm not on bugcontrol? [17:15] szim90: hold on, I forgot the policy :) [17:15] bdmurray: what did we agree on when LP is upstream for a bug? [17:17] szim90: just try... if it works, it works. otherwise not :) [17:19] it would appear that the developer page links to the launchpad page for bugs. [17:19] my personal opinion here is: mark this bug as incomplete and address the other user who is affected directly if he still does have this problem [17:19] ad can provide the neccessary information [17:19] s/ad/and [17:20] thekorn: well, it seems like a dup, so my question is just what is our LP is upstream dupe policy for non-Ubuntu only apps [17:21] hmm, good question, do we have one ;) [17:22] thekorn: I thought we decided on one at the last meeting [17:22] * micahg goes to check the chat logs [17:22] * thekorn greps for the meeting logs [17:23] micahg, how can you know, you were late ? :) [17:23] thekorn: the discussion didn't start till I got there as it was my item :) [17:24] and the IRC logs for the channel are published, but I'm not looking at those [17:25] szim90: the consensus seems to have been to add a task on the upstream bug [17:25] wait that's not right [17:25] we seemed to skip this use case entirely which was the whole point... [17:25] hmm, for me it seems we did not cover the duplcate case [17:25] thekorn: right [17:26] and no one seems to be around :) [17:26] ok, I think in this case it would make sense to just set the bug to incomplete [17:26] as the user who is affected by it if it is still a problem [17:26] alright. Should I put a link in the comments to the other one, as the other bug as a workaround. [17:26] and if he can give more information [17:26] if not, close it [17:27] if so, let's start to find a solution at this point ;) [17:27] szim90, I think this would be great [17:28] so, final consensus is mark as incomple - Needs info, and add a note in the comments that the upstream bug as a workaround for other users. [17:29] that's how I would act in this situation, it will atleast reduce the amount of bugmails send [17:30] ok. Also, though I'm not a developer, is it possible to solve bugs like this on the packaging level (all that's needed to resolve this is to edit one of the .desktop files) [17:30] szim90, for your info " KaiserSoze" is the other user who clickt the "this bug affects me too" button, just in case you would like to adress him directly [17:31] szim90, is this desktop file shipped as part of the upstream release? [17:31] or added by an patch in the packaging process [17:32] I'm not sure. [17:33] szim90, the best way here is to solve this in the project itself [17:33] to keep the diff to upstream as small as possible [17:34] but you can ofcourse fix it in the package and send the patch upstream [17:34] alright. I mentioned it because this bug has been open in upstream for a year, and it seems like a simple fix. [17:34] Hm, never patched anything before. [17:35] szim90, maybe it is because upstream is inactive for a long time [17:36] alright, I'll look into patching it and sending it upstream. And I marked 485212 as incomplete. [17:37] super cool, thanks szim90 [17:37] no problem, thanks for the help thekorn and micahg. And I'll email KaiserSoze about the bug. [17:38] szim90, he is subscribed to the bugreport, so he will get your comments by mail [17:39] even better. [17:39] Thanks. [17:53] micahg: I am here === PrototypeX29A is now known as widersach === yofel_ is now known as yofel === cjohnston is now known as FFEMTcJ === FFEMTcJ is now known as cjohnston [22:09] hey everyone [22:10] hggdh: around? [22:17] nigel_nb: yes [22:18] hggdh: I was just goin through the list of bugs we've been asked to close as invalid because of apport error [22:18] I can't see some of the bugs or change status in the ones I can see [22:18] this may be due to the fact that some of the bugs are private [22:19] now, for changing status, you should be able to [22:20] I think when a bug is parked as dup of a private I can change status too [22:20] I sort of doubt ;-) [22:21] correction [22:21] the private status should trump all else. If it does not, I would consider it as a bug in itself [22:21] s/can/can't [22:21] ah [22:21] which means *evil grin* the bug control has to do a whole lot of work [22:21] yes... [22:21] I tried.. ;) [22:22] hggdh: did you see the scrollback about dups for upstream bugs where lp is upstream? [22:22] micahg: no, will scroll back and read it [22:22] hggdh: around 11:30 AM [22:22] nigel_nb: give us the bug #s that you cannot change, and we will do it [22:23] from around 90 to 125 i picked 5 in random [22:23] all of them were unchangeable [22:23] i.e., in the last of bugs, from line number 90 to 125 [22:31] is there any way to give a list of bugs and only see them === widersach is now known as PrototypeX29A [23:40] micahg: read the backlog, but I am confused on what is the question [23:41] brb