[12:27] only if its packaging related ... or how to better integrate in gnome/kde/xfce [12:27] should a specification be encouraged [12:28] though most gnome/kde/xfce integration work should be done upstream as well [12:28] only those that are ubuntu specific should stay with us [12:28] gnomefreak: did 2.0.0.4 tbird bring font improvements? [12:28] looking [12:29] can you wipe your profile to be sure that you have the *new* default settings [12:29] little bit [12:29] or got to advanced config editor and "reset" all black/bold entries [12:29] about fonts [12:29] can you do that? [12:29] i mean i think your settings are tweaked now ... since you changed them to test something [12:31] there is no reset to defaults [12:31] :( === asac_ [n=asac@debian/developer/asac] has joined #ubuntu-mozillateam [12:39] ys its a bit better [12:43] asac: what do you mean you dont like the feature request templete? what is wrong with it [12:55] gnomefreak: as i said ... i like it ... just only for feature requests that are ubuntu only [12:55] otherwise send them upstream [12:55] we cannot deal with a huge swamp of blueprints :) [12:56] superbe flashplugin-nonfree doesn't build for me in gutsy [12:56] they are only for mozilla in ubuntu that we deal with anyway. we cnat change upstream source [12:56] asac: your not updating that are you? [12:56] yes right ... and thus we need a second feature request template :) [12:56] gnomefreak: i am trying to build atm [12:56] :) [12:56] asac: last i heard its borked [12:57] hmm [12:57] the new version of flash has regression [12:57] looks like [12:57] that was as of a week or so ago [12:57] i think its cdbs that has regression [12:57] hmm [12:57] and we know adobe isnt fast [12:57] its doesn't build at all [12:57] adobe is not involed in that process [12:57] download happens during install afaik [12:57] asac: good once installed it doesnt work either [12:57] :) [12:57] yeah [12:58] migth be true ... but that is beta release afaik [12:58] let me ping crimsun and see if they fixed it yet [01:01] asac: 19:01 < crimsun > gnomefreak: if you mean upstream's beta 3 (9.0.60.120), then yes, it was and still is utterly broken - a 100% regression. [01:03] yeah as i said ... still beta [01:03] well its update 3 not so much beta3 [01:03] but yes same thing [01:04] asac: btw did you see pittis bug report on gnash? [01:04] i think hjmf posted it above somewhere [01:04] haha flash of course doesn't build on amd64 [01:04] stupid me [01:04] lol [01:05] are we able to make gnash open all flash version applets [01:22] what do you mean? [01:23] if you refer to the fact that gnash doesn't work for some flash files (still quite a lot i guess) ... then the answer is definitly no. [01:23] ill get with you tomorrow there is a bug pitti reported about gnash crashing on a site, i tested it it doesnt crash but wont play the flash applet [01:23] it will still take some time till everything plays fie [01:23] gnomefreak: i tested [01:23] i got a crash file after a few attempts [01:24] interestingly it started to play well the first time [01:24] i didnt :( [01:24] but then never did [01:24] and it never played said i was missing plugin but couldnt name the plugin [01:24] i think if you try multiple times you will get a crash [01:24] maybe you need to clean up your crash directory [01:24] do you have -ugly installed? [01:24] and -ffmpeg [01:25] i will test more later tonight/tomorrow(more likely) and see if i can get it to crash [01:25] asac: i have all codecs installed [01:25] all? [01:25] what does that mean? [01:25] all needed for mp3 flash freeformats [01:25] gnomefreak: there might be more [01:25] can you get a console output? [01:26] it should print what codec is tried [01:26] please capture console output of firefox [01:26] and show [01:26] :) [01:26] never tried i will try later (its dinner time) [01:26] you have link handy? [01:26] yeah just post .. i will look tomorrow [01:26] yes [01:26] http://www.tower-restaurant.com/index2.html [01:27] but start from console [01:27] ty yes i know :) [01:27] :) [01:27] go! [01:30] hmmm it is crashing but i dont get notified i will post to bug again later [01:31] asac: output from term. http://gnomefreak.pastebin.ca/575310 ill bbl [01:59] what is bug number for that bug? [01:59] search for newest [01:59] I am out :) [01:59] ;= [01:59] its just one click in bug list :) (newest first) [02:00] found it [02:00] thx [02:00] ty :) have a good night [02:01] u2 [02:01] sleep well [02:02] u2 === DarkMageZ [n=richard@ppp59-167-4-195.lns1.syd7.internode.on.net] has joined #ubuntu-mozillateam === smcgraw [n=shane@12-216-188-54.client.mchsi.com] has joined #ubuntu-mozillateam === smcgraw [n=shane@12-216-188-54.client.mchsi.com] has left #ubuntu-mozillateam ["Leaving"] [07:38] asac: tomorrow I'd like to start working on nspluginwrapper if you have the time. === cjwatson [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk] has joined #ubuntu-mozillateam [09:58] Admiral_Chicago: when is tomorrow? [09:59] Admiral_Chicago: like today? === bluekuja_ [n=andrea@host223-216.pool8248.interbusiness.it] has joined #ubuntu-mozillateam [10:13] yes, I said tomorrow yesterdau. today. [10:14] asac: i'm going to bed now. probably awake in a few hours [10:15] Admiral_Chicago: hehe ... ic, sleep well :) [10:16] thanks. night [10:37] asac: i uploaded crash report to gnash bug gave link to term output and tested with flashplugin-nonfree (flash works fine) [10:57] gnomefreak: good ... can you still reproduce the "missing plugin dialog" [10:57] ?? [10:57] like what you mentioned in one of initial comments on bug? [10:58] no [10:59] i think that was because i had removed gnash for testing forgot to install it again si i installed it and never restarted firefox [10:59] ok [10:59] interesting effect anyway :) [11:00] if you ever see this again, remember to note how you get there :) [11:00] theres a new glib in NEW (maybe has been pushed, not sure yet) so you think glib could have caused crash? [11:00] asac: i will [11:02] did you ever ping seb about vlc/glib? [11:02] although if it was glib flash would crash as well i would think [11:08] morning [11:08] asac: I got rid of all the mt-reject-candidate bugs [11:09] gnomefreak: your gnash crash report lacks the coredump [11:23] hjmf: yohooo :) === hjmf [n=hjmf@138.Red-83-45-117.dynamicIP.rima-tde.net] has joined #ubuntu-mozillateam [11:34] hjmf_: what is bug count now? [11:35] already below 500 ? [11:35] hjmf_: that is how it shows in the report [11:35] it shows a few chars than a = [11:35] im gonna have to assume apport is doing that [11:36] rdev scanner video [11:36] CoreDump: base64 eJwDAAAAAAE= [11:36] gnomefreak: yes ... he raised importance and glib bug and admitted that its also a glib bug [11:36] i think its done that way to be more private as they said it will do [11:36] e.g. glib regressions [11:36] yay [11:36] ... while applications contribute their own share [11:36] :) [11:37] well fix glib and we will see about apps end of it [11:37] yes [11:37] he has milestoned the bug [11:37] so we won't forget for tribe-3? [11:37] tribe 2? [11:37] asac: we still have 567 open reports [11:37] oh 3 [11:37] gnomefreak: look your self [11:37] might be tribe-2 [11:37] hjmf: hmm [11:38] hjmf: given that i pushed tbird bug count down to 75 (one result page) its still too much :) [11:38] but i think 550 would be a good count to start new crash flood :) [11:38] Admiral_Chicago: we should dig into old reports and reject them all!!!!! :-P [11:38] hjmf: we really have not so many crashes without duplicate? [11:38] asac: I meant [11:39] i thought there should have been more [11:39] ... much more [11:39] hjmf: yeah ... old reports can be closed more aggressively ... but i thought that the "no old crash rule" would elimate loads of bugs [11:39] asac: theorically only those tagged as mt-confirm are the crashes w/o dups [11:39] yeah [11:40] so its me who is blocking this, by not working through that list? [11:40] asac: lol, maybe :D [11:40] hmm 69 results in mt-confirm at needs info [11:41] hjmf: didn't you mark all these mt-reject-candidates? [11:41] 567-69 = < 500 ! [11:41] or which ones did we mark mt-reject-candidates? [11:41] mt-reject-candidates are those that are crashes, mt-confirm, w/o testcase and > 2 month old [11:41] hmmm they are younger than 2 month [11:42] yep [11:42] i don't think if we should close them :) [11:42] 1'5 months ;) [11:42] asac: hes still calling vlc crasha vlc bug [11:42] hmm maybe we should put those waiting for dupe do a different tag: mt-waitdupe [11:42] :) [11:42] so its gets out of that mt-confirm list [11:43] though i could just skip all crashes when reviewing [11:43] ah ok [11:43] but if they have a testcase they should be mt-confirm :) [11:43] but that should be the minority [11:43] so a new crash might be tagged directly as mt-waitdupe + mt-needtestcase [11:43] if it doesn't have a test case [11:43] hjmf: right [11:44] ok, let me spam you in a while :) [11:45] yes maybe use 'mt-nodup' or mt-waitdup [11:45] e.g. without 'e' [11:45] its what is used in likely-dup already [11:46] if those are gone then the mt-confirm pocket will be something one can process serious [11:46] ly [11:46] because its a handable amount of issues in there [11:46] OK, a quick search shows that 'need-info' with mt-confirm + mt-needtestcase are 176 [11:47] so those are likely to become mt-waitdup + mt-needtestcase [11:47] and candidates to mt-reject after 2 moths [11:47] *months [11:47] bug 112925 is somehow not in right state, right? [11:47] Launchpad bug 112925 in firefox "eclipse crash, when spawning browser" [High,Needs info] https://launchpad.net/bugs/112925 [11:47] is that catched by bughelper already? [11:47] e.g. mt-confirm + mt-needtestcase is illegal? [11:47] lets look at bughelper result and search for bug :) [11:48] hmmm http://daniel.holba.ch/bugs/firefox.html [11:48] looks rather smallish [11:48] hmm, I'll do a review by hand, maybe there are a few with wrong tags [11:48] i can't believe that we are down to that few [11:49] hjmf: i can do that ... will do a quick mt-confirm run later [11:49] asac: Admiral_Chicago did an update of the clues iirc [11:49] asac: OK [11:50] Admiral_Chicago: why is the amount of bugs found by clues so small now? [11:50] or did someone go over the triaging bugs and fixed them? [11:50] asac: do you want me to start changing mt-confirm to mt-waitdup for those that are clear [11:50] hjmf: if you want :) [11:51] asac: there is a mail from Admiral_Chicago in the mail list saying he fix some clues [11:51] iirc [11:51] gnomefreak: bug 114837 -> why don't you tag Needs Info bugs? [11:51] Launchpad bug 114837 in firefox "firefox needlessly offers to remember passwords when posting comments on livejournal" [Undecided,Needs info] https://launchpad.net/bugs/114837 === andrea__ [n=andrea@host185-170-dynamic.56-82-r.retail.telecomitalia.it] has joined #ubuntu-mozillateam [11:51] asac: you said dont use needs info [11:52] when i asked you about that tag [11:52] yes ... you should use another tag [11:52] its mt-needtestcase most likely [11:52] iirc he says how to do it [11:53] ... at least looking at the bug you currently try to gather data to finally have a testcase [11:53] e.g. get version numbers et al is done during needtestcase [11:53] if you think there is enough information that a try to reproduce might be feasible use mt-needtester [11:55] we need a needs info tag or something like it as some thing alike as our tags on the wiki page doesnt fit all bugs [11:55] gnomefreak: imo they do fit most if not all [11:55] gnomefreak: which bug do you mean? [11:56] gnomefreak: just think different: the tags express what is needed to go ahead [11:56] i dont have numbers off hand [11:56] gnomefreak: if there is no testcase -> mt-needtestcase [11:56] if there is a testcase that looks sound -> mt-needtester [11:56] so if i can reproduce bug set it to mt-confirm? [11:57] gnomefreak: yes, but take care that there is good description of testcase in summary [11:57] (e.g. in bug description= [11:57] whats different from mt-confirm to mt-upstream? [11:57] mt-confirm is used to review bugs before they are transitioned to next state ... e.g. its a pure QA state [11:57] nothing else should be done [11:58] mt-upstream is in state Confirmed ... and signals that people should do upstream triage [11:58] k [12:00] gnomefreak: actually mt-needtestcase should be the standard state of Needs Info ... if you don't know what to choose or how to reproduce, using that tag is probably the right choice [12:00] k [12:00] mt-needtester is only useful if there is someone claiming that the testcase is reproducible, but we don't see it ... so we try to find someone else who can confirm that the bug appears with those testcase instructions [12:08] hjmf: bug 73493 [12:08] Launchpad bug 73493 in firefox "Crash M_get_input_context" [Medium,Confirmed] https://launchpad.net/bugs/73493 [12:08] ... yeah ... found triaging triaging bugs from bughelper page ... [12:09] ;) [12:09] likely-dup i would say :) [12:09] which is resolved, right? [12:10] can you merge that into master bug? [12:10] asac: yes! [12:11] I didn't notice it because of the bad lp search engine, since the misspell in the summary [12:11] lol [12:11] bug 74796 [12:11] Launchpad bug 74796 in firefox "Firefox Crash" [Medium,Needs info] https://launchpad.net/bugs/74796 [12:11] found previously forgotten crash [12:11] hjmf: yeah ... finally the clues are worth something :) [12:12] asac: btw that bug should have been the master :) [12:12] though not perfect because they tend to spit out "triaging bugs" for bugs that have upstream target [12:12] hjmf: really ... hehe ... yeah [12:12] maybe he is a smart guy ... he didn't receiv loads of spam :) [12:13] asac: good thought :) [12:13] bug 73493 [12:13] Launchpad bug 73493 in firefox "[EDGY] firefox crashed [@IM_get_input_context] [@nsWindow::IMELoseFocus] [@nsWindow::IMEDestroyContext] (dup-of: 85627)" [High,Needs info] https://launchpad.net/bugs/73493 [12:13] Launchpad bug 85627 in firefox "MASTER firefox crash [@ IM_get_input_context] " [High,Fix released] https://launchpad.net/bugs/85627 [12:13] fixed :D [12:14] ok good one project on hold for a while i hope [12:15] gnomefreak: he? [12:15] kxdocker [12:16] sent email to debian maintainer for it as its no longer supported upstream [12:16] asac: mt-waitdup bugs: 48 ---- mt-confirm bugs: 20 [12:16] and its borked in feisty and gutsy im trying to get it dropped from repos [12:16] hjmf: another previously unseen crash: bug 94175 [12:16] Launchpad bug 94175 in firefox "weather applet crashes on logout" [High,Needs info] https://launchpad.net/bugs/94175 [12:16] asac: I'll review them for mistakes, but I guess you can review the mt-confirm ones now [12:16] i tagged it mt-needretrace [12:16] asac: OK [12:17] hjmf: ok ... i will not go to mt-confirm before later this afternoon/early evening [12:17] i have to finish nspluginwrapper spec to allow Admiral_Chicago to really work on it :) [12:17] now doing triaging bugs :) [12:18] asac: good :) [12:23] what tag are you working on asac === gnomefreak gonna take a tag and go with it just not sure what one yet [12:25] gnomefreak: i am currently working on triaging bugs ... feel free to go for mt-needtestcase mt-needtester [12:25] and mt-upstream (e.g. try to find upstream bug) [12:25] k [12:26] gnomefreak: what tag has most bugs accumulated? [12:26] are all tags still within "manageble bounds"? [12:26] not sure but im seeing needstestcase needs clean up [12:26] lol [12:26] (e.g. don't look at mt-confirm ... thats going to be cleaned up) [12:26] yeah needtestcase should be a heavy state [12:27] most will probably not go through that state [12:27] once marked upstream what tag is used? [12:27] if has a good description of testcase (step by step) then push it to mt-needtester [12:27] if a bug couldn't come up with a testcase for 2/3 month ... reject [12:28] gnomefreak: if you find upstream bug, mark it accordingly and set tag mt-confirm (e.g. with state confirmed) [12:28] it has upstream confirmed [12:28] i will look at those and push to "In Progress" (without tag) [12:28] if the upstream bug is ok [12:28] gnomefreak: so its simple ... if you have upstream bug, tag mt-confirm [12:28] done [12:28] k [12:29] i will verify that bug is ok and confirmed/on-track upstream [12:29] then go in progres [12:29] looking becasue you asked for testcase in upstream bug too [12:30] me? [12:30] which one are you on? [12:32] https://bugzilla.mozilla.org/show_bug.cgi?id=362955 [12:32] Mozilla bug 362955 in General "Firefox makes X run out windows" [Normal,New] [12:33] leave ff open for 4 days thanit gives you that i guess would be testcase [12:33] doesnt matter they found issue in granparadiso [12:34] sinceits confirmed upstream testcase shouldnt be needed [12:35] i leave pc on for days at a time and ff is normaly open that whole time and it never happens to me [12:36] gnomefreak: this is "In Progress" then [12:36] sure thing ... no need to ask [12:36] remove all tags [12:36] thought so [12:52] im willing to bet bug 91504 is caused by something automatix installed (maybe he knows maybe not but automatix is always involved with weird shit happening. he gave testcase but we cant test it since im gonna assume the links he gave are not for anyone to sign into. will think about this over a smoke [12:52] Launchpad bug 91504 in firefox "Firefox frequently crashes [@js_MarkScopeProperty] " [High,Needs info] https://launchpad.net/bugs/91504 [01:10] gnomefreak, see if he's running any interesting plugins or addons :P [01:11] DarkMageZ: already commented [01:11] its either firebug or automatix in my best guess but waiting for reply [01:20] ok i finished doing all triaging bugs :) [01:20] oh no [01:20] its getting bigger [01:21] lest wait at least another run before looking at bugs again [01:21] 555 open now :) [01:22] what is mt-waitdup? [01:22] yeah ... for crashes only ... to get them out of the mt-confirm list [01:22] if they wait for duplicates [01:22] ther eis upstream bug as hjmf has stated. reguardless that new profile fixed it (you shouldnt have to remove profile) [01:22] we don't let crashes without duplicates to confirmed [01:23] bug 108006 mozilla 375154 [01:23] Launchpad bug 108006 in firefox "[FEISTY] firefox crashed [@mozSpellChecker] [@mozSpellCheckerConstructor] " [High,Needs info] https://launchpad.net/bugs/108006 [01:23] Mozilla bug 375154 in Spelling checker "crash [@ mozSpellChecker::mozSpellChecker] " [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=375154 [01:24] they look very much related looking into them so im thinking its safe to remove tags and mark upstream [01:24] gnomefreak: you don't need to look at mt-waitdup bugs [01:24] 555 will be back up to 669 in a day or so [01:24] asac: im not its set meedstestcase [01:24] the tag exists to be out of site [01:24] but also has wait tag [01:25] yeah ... thats transitional ... afaik hjmf gets over all mt-waitdup now and removed such tags [01:25] we just started to mark them mt-waitdup [01:25] can i remove it when marked upstream? [01:25] gnomefreak: wait ... its mt-needtestcase because without dupe that have testcase can go to confirmed [01:25] as well [01:25] so yes ... keep it ... and see if bug has already a valid testcase [01:26] if so move to mt-confirm [01:26] but that implies that you can reproduce :) [01:26] cant reproduce as it seems to be a profile issue [01:26] then keep it in that state ... and let the mt-waitdup timer kill the bug :) [01:26] new profile doesnt happen [01:26] k [01:27] maybe you can get info how to setup a profile that crashes this way [01:27] reporter might be able to compare profile by looking at files inside et al [01:28] so crashes we dont wait a month than reject like everything else? [01:31] gnomefreak: 2 months w/o dup or w/o a testcase [01:32] k [01:32] gnomefreak: however if it happens to appear a dup in the future there is no problem [01:32] gnomefreak: as I after retrace (mine or apport retracing service) I look for dups even on rejected reports [01:33] gnomefreak: 2 months w/o dup AND w/o a testcase [01:34] i feel that is a bit long since firefox releases fixes every 6 monthsish [01:34] sorry [01:34] every month [01:34] I have no problem to reduce the time lap :) [01:35] like bug 109252 should be closed as he nolonger uses kde and that is crash due to qt [01:35] Launchpad bug 109252 in firefox "[FEISTY] firefox crashed [@ setColors] [@ realize] -- from libqtengine.so" [High,Needs info] https://launchpad.net/bugs/109252 [01:35] hes waiting for kde4 and we wont see that till 8.04 [01:36] yes ... anyway crashes don't really depend on reporter being available [01:36] ... if we receive dupes its ok [01:36] of course he will not be able to help to come up with a step-by-step testcase [01:36] ... so without dupes this bug is doomed to die :) [01:36] gnomefreak: it will be marked as mt-reject-candidate in 4 days [01:37] i don't think we need to reduce period we wait for dupes [01:37] ... its just important that bugs disappear semi automatically :) [01:37] at some point [01:37] vs. stay open forever [01:37] asac: that might happen with mt-needtester reports [01:38] maybe we should put there a time limit too [01:38] mt-needtester at need info state ofcourse [01:38] hjmf: yes ... for all tags [01:38] :) [01:38] but actually time-limit after tag was set [01:38] :) [01:39] i mean for all tags that wait for something to happen [01:39] ... that don't depend on our own lazyness (which should only be mt-confirm) [01:40] So far I use time limit for mt-needreport (20 days) and the limit of 2 moths for mt-waitdup [01:40] I mean automatic time limit [01:42] if after a month the user cant come up with a test case why wait? what will change? another crash == another bug report [01:43] https://wiki.ubuntu.com/MozillaTeam/Bugs/States [01:43] mt-needinfo is documented there [01:43] should be dropped from that page [01:43] i will grop it now [01:43] drop. [01:44] gnomefreak: thanks [01:44] from there? [01:44] why not tags page? [01:44] i think we should review that documentation as it should provide detailed infos on what task is associated with each tag [01:44] tags page problay doesn't have that tag listed [01:44] its left-over from some time [01:44] it does [01:44] dunno if i added it or who [01:45] needs info is a valad bug state [01:45] yeah needs to be dropped as well [01:45] will you do as well? [01:46] i will drop from both but im not sure why you want to drop it from states since we ask for info we set bug to needs info state [01:49] mt-reject-candidate and mt-waitdup need a description in that page [01:50] needsinfo tag is gone from tags [01:50] yes ... IN Progress should be explained as well [01:50]