[12:32] will your "script" still detect that bug to match dupes? [12:34] yes it will, you can safely reject it. :) [12:35] hjmf: you have any idea how many out of the 611 bugs are non-crash bugs? [12:35] i somehow have the feeling that we are kind of blinded for "normal" bugs atm [12:35] new might be served properly atm, but olds are most likely never reviewed [12:36] i mean we could'nt even add a "crash" tag [12:36] as we cannot use "not contains" tag in search query [12:37] asac: true [12:38] we should take the effort to review old reports [12:38] most should be closed [12:38] yeah ... main problem is I like to go over bugs multiple times [12:38] go about "real" bugs [12:38] but i can't ... but maybe most aren't really bug [12:38] s [12:39] probably [12:39] reviewing old reports is boring :) [12:39] so I have no idea :) [12:39] hmm [12:40] maybe we should add a job post :) ... review old bugs ;) [12:40] e.g. today I tried to retrace all mozilla-thunderbird mt-needretrace [12:40] hjmf: only shit came out of it, right? [12:40] and the oldest couldnt be retraced rightly [12:40] yes [12:40] hjmf: yes ... actually can we abort retracing if there is a warning for any of the core libs [12:41] i found lots of traces for firefox that made no sense [12:41] e.g. they had a stack that didn't match anything closely related [12:41] e.g. there are no such method transitions at all [12:41] that's why I like to retrace myself [12:41] I can see the apport warnings [12:41] so what do you check? [12:42] do you ever abort? [12:42] the apport stderr for warnings about packages not found [12:42] i mean if the stacktrace has valid symbols :) [12:42] no, I automatically reinstall the right dbg version [12:42] "valid looking" actually [12:42] I match the reporter's firefox version [12:43] thing that I cannot do with thunderbird [12:43] as I only have one -dbg [12:44] I have a good cache pool of old -dbg packages for firefox retraces [12:44] since we started to retrace [12:45] so I can retrace old reports in firefox [12:45] so those packages that pitty's repo misses by obsolete I still have them [12:48] thats fine [12:49] hjmf: can you pick two recent ones and look at the code lines [12:49] and tell me if they make sense [12:49] ... maybe those i rejected where not by you or early ones where maybe some important warnings might have gone unseen [12:49] or maybe johns backtrace ... i don't remember [12:50] hjmf: the point is that i saw few traces that really made sense [12:50] hjmf: and i have the feeling that we probably need to remove some optimization option during build to get good squezes [12:51] hmm, those confirmed ones that matched upstream bugs looked right [12:51] I mean, our retraces matched upstream ones [12:52] asac: but that is for those I could find the upstream match [12:54] hjmf: yes some are valid [12:54] i think those that end up in gtk something should be fine [12:54] ... at least for the gtk part [12:55] how many "mozilla" only traces did you match with upstream? [12:56] e.g. bug 118287 retraced today [12:56] Launchpad bug 118287 in firefox "[FEISTY] firefox crashed [@free] [@js_FinalizeStringRT] (dup-of: 71702)" [High,Needs info] https://launchpad.net/bugs/118287 [12:56] Launchpad bug 71702 in firefox "MASTER Firefox Crash [@js_FinalizeStringRT] [@js_atom_uninterner] " [High,In progress] https://launchpad.net/bugs/71702 [12:56] hjmf: ok thats js engine [12:56] is upstream 267063 [12:56] js engine might be special case [12:57] hjmf: you matched a "layout" crash ? [12:57] hjmf: e.g. reflow something [12:57] or alike [12:57] asac: too late to remember those things :) [12:57] looking [12:57] cool [12:59] hmm, iirc the only upstream bugs I matched are part of those MASTER in state 'in progress' [01:01] hmm will look at a few new ones [01:01] and look if line numbers make sense [01:02] or at least function names make sense :) [01:02] asac: is true that I look daily for upstream's when I retrace and many of our retraces can be found at talkback reports [01:03] but almost none have an upstream bug open [01:03] hjmf: yeah ... i think that lots of traces make sense [01:03] but too many don't make sense [01:03] some might not make sense because if things really go bad, the stack is trashed as well [01:03] but that should not happen that often imo [01:03] though, it might be [01:04] those are the reports w/o a dup [01:04] we talked abit about that on uds [01:04] one likely optimization option that might improve the traces would be [01:04] -fno-omit-frame-pointer [01:05] nobody could really imagine what happends to the backtrace ... and in what specific situation this might cause troubles [01:05] hjmf: so what is the bugs w dupe vs bugs wo dupe ration in your opinion? [01:05] are they even? [01:05] i mean we have heavy weight crashers [01:06] like the one i closed (98) [01:06] and the ones you know .) [01:06] I found more dups than non dups [01:06] hjmf: thats good at least :) [01:07] i think i should do a master bug day soon [01:07] ? [01:07] review all master bugs [01:07] and see if they really make sense [01:07] you mean to close masters? [01:07] by looking at code [01:07] ah! [01:08] if they make sense ensure that they are really carried upstream [01:08] e.g. if there are talkbacks at least [01:08] because unless we see talkbacks for that its likely an ubuntu only issue [01:08] and needs to be evaluated further [01:08] e.g. maybe its ubuntu only, because we use some other version of libX [01:08] or something [01:09] or worse: its due to a patch we have :/ [01:09] I did that a couple of weeks ago for those mt-upstream (I was bored) [01:09] and some I couldn't find references upstream [01:09] but I don't remmember which ones [01:10] as I was just only playing a bit [01:10] :( [01:10] hjmf: you said you see that there are talkbacks [01:10] if there are tb [01:10] can you note the id together with the trace? [01:10] then we need to hurry because tb-ids are only valid for some period (e.g. 90 days?) [01:10] and post upstream asap [01:11] so they can't deny thats their crash :) [01:11] next time I'll be bored I'll do it :) [01:11] ah ... though you automagically search for talkbacks :) [01:12] don't need to do that if you do manual [01:12] I will post a couple of bug tags ... offer mentoring and then post on forum [01:12] the sooner the better [01:12] cool [01:12] one will be upstream triage :), which could exactly be that [01:13] or a dedicated MASTER bug Maintainer :) [01:13] but i think i dream too much :) [01:13] :) [01:13] it's the right hour [01:13] right.... :) night! [01:13] night! === DarkMageZ [n=richard@ppp167-203.lns4.syd6.internode.on.net] has joined #ubuntu-mozillateam === poningru [n=poningru@ip72-209-70-78.ga.at.cox.net] has joined #ubuntu-mozillateam === poningru_ [n=poningru@ip72-209-70-78.ga.at.cox.net] has joined #ubuntu-mozillateam === DarkMageZ [n=richard@ppp167-203.lns4.syd6.internode.on.net] has joined #ubuntu-mozillateam === poningru__ [n=poningru@adsl-074-245-140-197.sip.gnv.bellsouth.net] has joined #ubuntu-mozillateam === poningru [n=poningru@ip72-209-70-78.ga.at.cox.net] has joined #ubuntu-mozillateam [08:21] whats IM_get_context ? === JenFraggle [n=jen@91.84.43.217] has joined #ubuntu-mozillateam [09:09] hey there JenFraggle [09:15] JenFraggle: i've written a road map of the next few weeks with clue files, we are halting work for right now, i just need to grab some information from the bugsquad people before we can do more work [09:18] JenFraggle: i'll be emailing you shortly however...bed time noe [09:18] now* [09:19] i thought you were up late, it;s 8:20am here [09:20] hehe, it's 2.20 am here [09:20] JenFraggle: where do you live (I ask so i can put a flag on Kworldclock) [09:20] uk === asac_ [n=asac@debian/developer/asac] has joined #ubuntu-mozillateam [09:23] ah okay. [09:23] ah the UK is all one time zone... [09:25] learned something new just now... === Admiral_Chicago goes to sleep [01:36] ok i am here ... in case i am needed [02:12] i posted a job :) [02:12] bug 118482 [02:13] Launchpad bug 118482 in firefox "[JOB] mozillateam assistant - MASTER bug maintainer" [Undecided,Unconfirmed] https://launchpad.net/bugs/118482 [02:14] ok i am off doing something else i pushed back for a while === JenFraggle [n=jen@91.84.43.217] has joined #ubuntu-mozillateam [03:03] anyone can confirm bug #90410 by reproducing the test case reported by the OP in his last post [03:03] Launchpad bug 90410 in thunderbird "[EDGY] mozilla-thunderbird crashed [@nsSaveMsgListener::OnStopRequest] [@bridge_create_stream] [@nsMsgProtocol::OnStopRequest] " [High,Needs info] https://launchpad.net/bugs/90410 [03:03] ty in advance :) [03:04] asac: cool job request :) === gnomefreak [n=gnomefre@ubuntu/member/gnomefreak] has joined #ubuntu-mozillateam [03:23] hjmf: that is dupe [03:23] of fat32 issue [03:23] i am not sure why it crashes for him [03:24] This error cannot be reproduced: Restarting and saving the same email again worked perfectly. [03:24] asac: the guy says he is able to reproduce it always [03:24] crazy [03:24] hmm [03:24] where do i have a fat32 partition [03:24] hmmm [03:24] i guess my usb stick has fat16 :( [03:24] lets see [03:25] hmm its vfat [03:25] in mount [03:25] hjmf: you know if its the same? [03:25] or is vfat really fat 16 :) [03:26] ok i will try :) [03:27] hjmf: i guess i will rename title [JOB] [HELP] [03:27] e.g. job sounds too much not-fun :) [03:27] hjmf: so any mail? [03:28] hmm just saved a mail without crash [03:29] maybe vfat is not fat32? [03:29] i mean it doesn't even fail [03:29] e.g. when using .eml extension nor .txt [03:30] found so far another related report (with same root cause): bug 92670 [03:30] hmm ... itersting thing is that .eml really fails ... but without a dialog :) [03:30] Launchpad bug 92670 in mozilla-thunderbird "Save email from IMAP folder fails silently if filename contains invalid characters" [Medium,Needs info] https://launchpad.net/bugs/92670 [03:30] *fails silently* :) [03:30] hmm [03:31] no it only fails silently when long subject [03:31] but lets see i try again with the mail that just failed silently [03:31] hmm its not there [03:31] but filename starts with [ [03:31] which might be a problem [03:31] though no error message at all [03:32] looks like fat really has loads of problems [03:32] ... 92670 is not a crash as was 90410 [03:33] .. not sure at all if 90410 retrace is good [03:34] cannot find any related stuff upstream [03:35] hmm [03:35] maybe "fails silently" is known upstream? [03:35] it probably has been posted :) [03:35] this does not sound like a bug that is ubuntu specific [03:36] no, but I started to look for a stack match :) [03:36] if its ubuntu only, then its likely the mount options we use for fat by default [03:36] dunno if they differ from what other distributions do [03:36] will look for 'colon', fat32... etc issues [03:37] ok i just set the silently bug to mt-upstream [03:38] oops did i post my question to the wrong bug? [03:39] ah ... missed a reload in another window [03:39] ok [03:48] actually I'm not able to find such upstream bug. I'll resume the search later (noted) :) [03:53] bugzilla 374789 [03:53] bugzilla bug 374789 [03:53] mozilla bug 374789 [03:54] Mozilla bug 374789 in Download Manager "unable to download to vfat volume" [Major,Unconfirmed] http://bugzilla.mozilla.org/show_bug.cgi?id=374789 [03:54] mozilla 374789 [03:54] ok so both [03:54] mozilla bug 357493 [03:54] Mozilla bug 357493 in Lightning Only "Lightning unable to install if profile is stored on a fat32/vfat partition on Linux" [Major,Unconfirmed] http://bugzilla.mozilla.org/show_bug.cgi?id=357493 === gnomefreak [n=gnomefre@ubuntu/member/gnomefreak] has joined #ubuntu-mozillateam === poningru [n=poningru@ip72-209-70-78.ga.at.cox.net] has joined #ubuntu-mozillateam === poningru_ [n=poningru@adsl-074-245-140-197.sip.gnv.bellsouth.net] has joined #ubuntu-mozillateam === poningru_ [n=poningru@adsl-074-245-140-197.sip.gnv.bellsouth.net] has joined #ubuntu-mozillateam === poningru [n=poningru@adsl-074-245-140-197.sip.gnv.bellsouth.net] has joined #ubuntu-mozillateam === AlexLatchford [n=alex@82-44-193-109.cable.ubr07.haye.blueyonder.co.uk] has joined #ubuntu-mozillateam [07:28] hmm firefox is not letting me download a file [07:28] this is odd [07:29] yeah ... the daily odds [07:29] ;) [07:30] ah i see it, i was downloading a massive file into the wrong directory... [07:36] hehe [07:44] asac: can you help me at looking at a retrace for bug 113284 [07:44] Launchpad bug 113284 in gimp "[apport] jpeg crashed with SIGSEGV in _XSetLastRequestRead()" [Medium,Needs info] https://launchpad.net/bugs/113284 [07:44] its a gimpe bug but i'm not sure where the crash was [07:50] yes [07:50] what is it? [07:51] its completely useless [07:52] so hoping for more informative valgrind is better [07:52] oh i see [07:53] trunk is borked again [08:00] he? [08:00] is alpha5 out yet? [08:00] hmm not yet [08:00] last aggressive landings? [08:01] what broke gnomefreak? [08:01] patch it looks like [08:01] haha [08:01] be more specific please [08:01] im watching it this time [08:01] i can assume that a patch broke :) [08:01] Applying patch nspr_macro_backport_for_gfx_thebes [08:01] patching file xpcom/ds/nsExpirationTracker.h [08:01] Hunk #1 FAILED at 35. [08:01] 1 out of 1 hunk FAILED -- rejects in file xpcom/ds/nsExpirationTracker.h [08:01] Patch nspr_macro_backport_for_gfx_thebes does not apply (enforce with -f) [08:02] make: *** [debian/stamp-patched] Error 1 [08:02] interesting [08:02] did they add it as well? [08:02] can you look what is in that file at line 35 (and aroun +-20 lines) and paste it? [08:02] the file not the patch right? [08:02] yes [08:02] the file [08:03] just give me the first 200 lines :) [08:03] give me a few [08:03] should be not too expensive ;) [08:03] sure [08:03] coffee refill anyways [08:05] asac: http://gnomefreak.pastebin.ca/534153 [08:08] asac: ignore that one please somethign got messed up [08:08] asac: http://gnomefreak.pastebin.ca/534162 [08:09] #ifndef??? [08:09] hmm [08:09] can you fix it? [08:09] look at the diff [08:10] the #defines added there need to be in that file as well [08:10] gnomefreak ... go to build-tree/mozilla [08:10] call quilt push -f [08:10] then edit xpcom/ds/nsExpirationTracker.h [08:10] so there is no conflict anymore [08:10] you will figure out === gnomefreak would need to know what to edit [08:11] cant it failed to apply [08:11] look at the patch [08:11] you can [08:11] you can do instructions above [08:11] quilt push -f fails [08:11] yes [08:11] but now you have the conflict marked in file [08:11] xpcom/ds/nsExpirationTracker.h [08:11] go in there [08:11] fix the conflict [08:11] ah ok [08:11] the quilt refresh --diffstat -U8 [08:12] then you are done [08:12] maybe show me the new diff afterwards :) [08:12] it can be found in debian/patches/ after "refresh" [08:12] what will make conflict stand out? [08:12] nothing you saw it [08:13] ah [08:13] its <<<<<< [08:13] ==== [08:13] >>>> [08:13] usually [08:13] you should see those markers [08:13] i wish [08:16] asac: they are not there http://gnomefreak.pastebin.ca/534183 [08:18] the #include "prerror.h" is only in .rej file not in .h file [08:18] Admiral_Chicago: actually we don't need to request retraces for i386 as hilario will do them anyways :) [08:18] #include "prlog.h" in .h file [08:19] yes [08:19] you have to add what is in .rej [08:19] to .h [08:19] its basically an #include [08:19] and maybe #define? [08:19] do i take prlog out? [08:19] or are defines meerged [08:19] why? [08:19] it not in .rej only in reg file [08:19] don't drop [08:20] k [08:20] as i said [08:20] only add [08:20] what is in patch [08:20] to the reg file [08:20] is #ifndef a typo? [08:20] why? [08:20] its valid [08:20] k [08:20] means ... if not defined [08:20] in contrast to [08:20] #ifdef -> if defined [08:20] the patch has #ifndef NSEXPIRATIONTRACKER_H_ #define NSEXPIRATIONTRACKER_H_ [08:21] #include "prerror.h" [08:21] gnomefreak: no [08:21] only what is marked with + [08:21] everything else is just unmodified context [08:21] so you can better read it [08:21] you see the + lines in patch? [08:21] that is what is added by patch [08:21] if there ar - lines in patch then its removed by patch [08:21] yes [08:21] ... so much for patch basics :) [08:22] looking in wrong place needed to be lower :( [08:22] ok let me see here [08:23] the .rej and patch look the same [08:24] the same like what? [08:24] like identical [08:24] identical compared to what? [08:24] eachother looking at file now [08:25] hmmm [08:25] you will figure out [08:25] #include "prlog.h" is the only thing not in rej or patch [08:25] yes [08:25] which is why it failed to apply [08:25] because patch command didn't know what to do [08:26] so you just have to add what is in patch to the "new" file [08:26] so i have to add that to patch [08:26] no [08:26] oh [08:26] you apply the patch manually [08:26] then run quilte refresh ... to refresh the patch [08:26] editing patches by hand is the last step in becoming a patch expert :) ... first understand what patches are doing ,) [08:26] asac: thats backwards [08:26] manually [08:27] means by editing file [08:27] not by patch command [08:27] asac: the file has the include the patch does not [08:27] gnomefreak: ignore what the patch has except the + lines [08:27] everything else doesn't matter much [08:27] that looks like all comments though [08:27] it just serves you to find the place the + lines have to be added [08:27] #if... is not a comment [08:27] +/* asac: backported from trunk nspr [08:27] nor is #.... [08:27] those are instructions [08:27] and continues [08:28] yes add those comments as well [08:28] +*/ [08:28] +#define PR_STATIC_ASSERT [08:28] yes [08:28] its allright [08:28] you have to add *all* [08:28] those + lines [08:28] none of the includes have a + [08:28] (of course without + in front [08:29] gnomefreak: yes ... so don't add any include to the file [08:29] only + lines matter [08:29] read above [08:29] its all in there :) === gnomefreak goes to smoke, something is odd here [08:30] ;) [08:31] yeah ;) [08:31] first step is to understand what the .patch file and the .rej file actually means [08:31] maybe take a close look [08:31] you should be able to guess what they mean [08:31] ;) [08:34] what i mean is the patch has things that the file doesnt but there are no + for them [08:34] #ifndef NSEXPIRATIONTRACKER_H_ [08:34] #define NSEXPIRATIONTRACKER_H_ [08:34] [08:34] #include "prerror.h" [08:34] + [08:34] the #include line is not in the file itself but the patch [08:35] the + is on its own line than starts the comment area [08:36] same with .rej no + next to #include "prerror.h" [08:36] so i would assume it doesnt get added to file but than why is it in patch [08:38] ok i added all but the #include "prerror.h" [08:40] gnomefreak: don't add it [08:40] they dropped it intentionally [08:40] one other question besaides the one do i add the #include line, is if im adding the changes to the file do i really than need the patch? [08:41] and our patch doesn't need that header afaik [08:41] you JUST add changes [08:41] done [08:41] OK? === cjwatson [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk] has joined #ubuntu-mozillateam [08:41] good ... run quilt refresh --diffstat -U8 [08:41] and paste the new patch for me to review :) [08:44] http://gnomefreak.pastebin.ca/534256 === cjwatson_ [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk] has joined #ubuntu-mozillateam [08:45]