=== cjwatson_ [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk] has joined #ubuntu-mozillateam === tonyyarusso [n=anthony@ubuntu/member/tonyyarusso] has joined #ubuntu-mozillateam === Admiral_Chicago_ [n=freddy@adsl-68-255-99-153.dsl.chcgil.ameritech.net] has joined #ubuntu-mozillateam [06:08] gnomefreak: still around? === tonyyarusso [n=anthony@ubuntu/member/tonyyarusso] has joined #ubuntu-mozillateam === tonyyarusso [n=anthony@ubuntu/member/tonyyarusso] has joined #ubuntu-mozillateam === asac [n=asac@debian/developer/asac] has joined #ubuntu-mozillateam [09:56] hi! [10:50] does the link in bug 88317 crash for anyone? [10:50] Launchpad bug 88317 in firefox "firefox crash [@nsJSEnvironment::Init] [@LocaleToUnicode] [@nsViewManager::ForceUpdate] ..." [High,Needs info] https://launchpad.net/bugs/88317 [11:25] hi asac. It doesn't crash for me ^^ [11:26] same locale than the OP [11:28] asac: how was your trip? [11:30] yeah grewat [11:30] unfortunately, the weather was bad :) ... so we couldn't go to the beach [11:30] but was nice anyway [11:30] hjmf: thanks [11:30] i will reject it then :) [11:31] asac: im testing in feisty atm to see if it crashes for me [11:31] old reports without dupe should be closed :) [11:31] im installing feistys version of ffox [11:31] gnomefreak: cool [11:32] asac: does -trunk us the new nss nspr packages? [11:32] s/us/use [11:32] gnomefreak: yes [11:32] hmmmmmmm [11:32] i made it work [11:32] with system-nss et all [11:32] al [11:32] asac: might want to take a look at it [11:32] why? [11:33] whats the problem? [11:33] at least on friday it build well :) [11:33] asac: someone complained when installing it there was a problem overwriting one fo the old things that are in mspr [11:33] but not sure if he screwed up or not he left before i could ask [11:33] which versino? [11:33] the old one didn't use that [11:33] the latest [11:33] i think [11:34] gnomefreak: then don't bother ... can you install firefox-trunk? [11:34] darkmage was the one having problems [11:34] have you uploaded i386 build already? [11:34] i havent tried yet ive been on other things. yes all is uploaded [11:34] don't know darkmage [11:34] :) [11:34] k [11:34] gnomefreak: did you use my orig.tar.gz for -trunk? [11:34] yep [11:35] he was building it with other options so he might have scred up [11:35] screwed* [11:36] i cant remeber what .so package it was but it was one that we had to remove from firefox2.0 in firefox-install file [11:37] not crashing in feisty here either [11:38] he build on his own? [11:38] i couldnt find the ac_options in firefox-trunk.install or -install or whatever it is named [11:38] ok ... thats not supported :) [11:38] asac: yes [11:38] :) [11:38] during install it failed to overwrite something [11:38] there are no ac_options in firefox-trunk.install ... in that file there are just the files that will be installed [11:38] for him or for yxou? [11:38] yeah i notinced [11:38] him [11:39] gnomefreak: i think he messed up [11:39] ... at least if it built for you as well [11:39] im leaning that way too [11:39] it built fine here [11:40] oh btw i think i found the file in iceape for the prefferences example pref("browser....) but it doesnt list the one i need am i supposed to add it to the all.js file :( [11:41] trying to make use of the go button in the tool bar [11:42] ubuntu-1.1.x/modules/libpref/src/init/all.js is the path and file i was looking in [11:46] yeah right [11:46] you have to use dpatch-edit-patch ... then edit that file [11:46] and use ctrl-d to exit dpatch shell ... which will create the patch for you [11:46] gnomefreak: ^^^ [11:47] ok should i be cd'ed into top level or into /init/ [11:47] i am thinking like everyother patch be outside the source dir [11:47] he? [11:48] for dpatch-edit-patch you have to be in top-level i guess [11:48] no ... dpatch-edit-patch will do the magic for you [11:48] you just have to use it ... then edit ... then exit that shell [11:49] ok ill try it i have no fear [11:49] number of patch matter? [11:49] yes ... look at the readme inside the patches dir [11:50] that explains what numbers to use [11:52] k [11:52] brb brewing more coffee [11:52] k [11:52] i am already in my 2nd litre as well:) [11:54] hjmf: what time do you think should bugs sit in mt-confirm before we reject them if they neither a dupe nor a testcase? [11:55] hjmf: .... and can we automize this :) [11:58] asac: a couple of months? let me do it ;) [12:02] hjmf: hmm ok ... lets say 2+ month till it was reported ... and no testcase [12:02] hjmf: how can we figure out that there is not testcase ? [12:02] hjmf: do we need a tag? [12:03] asac: there is no readme anywhere that has anything to do with patches :( [12:05] there is however a 82_prefs.dpatch patch already [12:05] and it is same file i am patching [12:05] there should be a mt-needtestcase [12:05] gnomefreak: ok [12:06] that's the only way [12:06] gnomefreak: use that patch [12:06] e.g. use dpatch-edit-patch 82_prefs [12:06] oh [12:06] gnomefreak: don't use that [12:06] k [12:06] use: dpatch-edit-patch 82_prefs_ubuntu [12:06] gnomefreak: ok? [12:06] k [12:06] fine [12:06] and add .dpatch to the name or will it do it for me [12:07] hjmf: so we add to all that don't have a testcase ... mt-needtestcase? [12:07] hjmf: maybe we should use the 'testcase' tag to tag bugs that have one? [12:07] reject bugs with tag mt-confirm + mt-needtestcase + older 2m + No dups [12:07] yes maybe mt-hastestcase in needsinfo state? [12:08] hjmf: ok [12:08] once we have testcase we need testers [12:08] hjmf: mt-hastestcase is fine with me [12:08] ok [12:08] hjmf: can even be valid in confirm imo [12:08] i mean to use that tag [12:08] :) [12:09] hjmf: actually i would like to do that only with crashes [12:09] hjmf: can we do that? [12:09] hjmf: i have fear to close valid "normal" behavioural bug reports that we just triaged badly [12:09] we can issue a crontask for that if we are confident with the testcase tag [12:09] hjmf: maybe we shjould really use mt-needstestcase [12:09] to prevent such things from happening [12:10] might be a bit more work (e.g. tag every crash mt-needtestcase [12:10] not more work, that is pretty automatic [12:10] hjmf: yes ... for new retraces :) [12:10] yes [12:11] hjmf: but how does auto-retracer detect that there is no testcase atm? [12:11] no way, that has to do by hand :) [12:11] unless it is able to read and understand the bug summary :-P [12:12] hjmf: ok ... so maybe we shouldn't tag mt-needtestcase manually [12:12] but instead make those bugs appear in bughelper or by some smart query [12:12] so we can regularly review crashes for "maybe attached testcases" ? [12:12] "hjmf: ok ... so maybe we shouldn't tag mt-needtestcase manually" -> automatically of course [12:12] if we attach them first it is ok [12:13] hjmf: then? [12:13] I vote for a "has test case" tag [12:13] hjmf: yeah [12:13] or better as you say a "has test case" attachment [12:13] hmmm thats awfully verbose :( [12:13] that can't be deleted by error [12:14] eg if some one deletes the 'has test case' tag a right bug might be rejected [12:14] but what would mt-hastestcase do? [12:15] if we push the tag to mt-needtester it moves the bug along [12:15] hjmf: maybe we should not close automatically ... but tag something like "reject-candidate" [12:15] but a 'empty file' named "has test case" attached can do the trick [12:15] so we can manually process that list? [12:15] hjmf: hmmm ... but we cannot remove them :) [12:16] e.g. if the testcase is bad ... or someone made an error the bug will always have a testcase [12:16] right [12:16] asac: you are right, maybe "reject-candidate" it is safer for such automatic use [12:17] however we still need a confident way to look for a test case :) [12:17] ok ... lets think a bit more about this ... but using mt-reject-candidate appears to be ok [12:18] to me too. Let's think a bit. I'll make a draft and tell you in the next days [12:18] a draft in the wiki? [12:18] the other parts are easy: date, mt-confirm tag, no dups [12:18] asac: script [12:18] ah [12:18] ok [12:18] yes go ahead :) [12:19] k [12:19] its not that "dangerous" to just do it [12:19] because its just a tag :) [12:19] indeed at first it might only return a list of candidates (even safer) :) [12:19] and less messy [12:20] hehe ... right :) [12:20] though i would not mind if somehow 200 bugs just disappear :) [12:20] right :) [12:20] anyway ... mt-confirm list in needs info is now below 100 again :) [12:21] I've seen your early spam :) [12:21] maybe i rejected too aggressively ... but i don't think so ... we just cannot push that amount of crashes without dupe upstream [12:22] right ... and I can still search for dups while retracing looking for already rejected ones [12:22] so it is not a problem at all [12:22] to resque some one form rejected limbo [12:22] hjmf: really? ... cool [12:22] how can we bring those to attention? ... e.g. resurrection candidates [12:22] ? [12:23] don't worry for that, as I retrace bugs I open firefox to search for the new crash signature [12:24] it is the in the same script I use to post the new retraces [12:24] it is tricky, but does the trick for me [12:26] OK! tonight when I'll be back at home I'll start with that mt-confirm script and meanwhile I'll think how to solve the 'has test case' stuff [12:26] asac: i think i did it :) patch is in debian/patches it didnt put it in 00list im assuming i need to do that right? [12:27] hjmf: thanks so much! [12:27] asac: yw [12:27] gnomefreak: did you exit the dpatch shell? [12:27] gnomefreak: is there content in the new patch-file? [12:27] yep it created it in patches [12:27] ok ... then add it to the end of the list :) [12:28] sweet. do you need me to post this patch before i add it in gutsys iceape. right now it is being added to mt build to test it [12:29] gnomefreak: we have two bzr branches right? [12:29] i think so [12:29] gnomefreak: one is your private one the other ~mozillateam? [12:29] yes [12:29] just push it to yours [12:29] i take a look and then you can merge it to ~mozillateam [12:29] just push the full patches dir? [12:29] are the branches in synch otherwise? [12:30] gnomefreak: no ... you have to bzr add debian/patches/newpatchfilename.dpath === gnomefreak not sure if they are synced or not [12:30] then commit debian/patches/00list and that file [12:30] k [12:30] gnomefreak: just compare revisions [12:30] you can look in launchpad [12:30] if both have the same revno ... then probably they are in synch [12:37] ok finished all my changes. now i have to bzr adddebian/patches/newpatchfilename.dpath? [12:37] s/adddebian/add debian [12:39] yes [12:39] .dpath should be .dpatch? [12:39] the you commit the new patch file and the modified list ... with a decent commet [12:39] yes [12:39] k [12:39] comment [12:39] ;) [12:48] i think its doing it ill let you know when done [12:49] gnomefreak: cool [12:49] asac: btw the problem with trunk we were talking about was it failed to overwrite /path/to/libnssckbi.so [12:50] its not showing changes on LP yet [12:50] Launchpad could not mirror this branch 1 minutes ago. The error was: Knit ... [12:50] is the error on the page [12:51] https://code.beta.launchpad.net/~gnomefreak/iceape/ubuntu-1.1.x [12:51] i will ping LP guys after i get back from smoke [12:52] the page shows changes [12:52] though there is an error message as well [12:52] # [12:52] By John Vivirito