 will your "script" still detect that bug to match dupes?
[12:34] <hjmf> yes it will, you can safely reject it. :)
[12:35] <asac> hjmf: you have any idea how many out of the 611 bugs are non-crash bugs?
[12:35] <asac> i somehow have the feeling that we are kind of blinded for "normal" bugs atm
[12:35] <asac> new might be served properly atm, but olds are most likely never reviewed
[12:36] <asac> i mean we could'nt even add a "crash" tag
[12:36] <asac> as we cannot use "not contains" tag in search query
[12:37] <hjmf> asac: true
[12:38] <hjmf> we should take the effort to review old reports
[12:38] <hjmf> most should be closed
[12:38] <asac> yeah ... main problem is I like to go over bugs multiple times
[12:38] <asac> go about "real" bugs
[12:38] <asac> but i can't ... but maybe most aren't really bug
[12:38] <asac> s
[12:39] <hjmf> probably
[12:39] <hjmf> reviewing old reports is boring :)
[12:39] <hjmf> so I have no idea :)
[12:39] <asac> hmm
[12:40] <asac> maybe we should add a job post :) ... review old bugs ;)
[12:40] <hjmf> e.g. today I tried to retrace all mozilla-thunderbird mt-needretrace
[12:40] <asac> hjmf: only shit came out of it, right?
[12:40] <hjmf> and the oldest couldnt be retraced rightly
[12:40] <hjmf> yes
[12:40] <asac> hjmf: yes ... actually can we abort retracing if there is a warning for any of the core libs
[12:41] <asac> i found lots of traces for firefox that made no sense
[12:41] <asac> e.g. they had a stack that didn't match anything closely related
[12:41] <asac> e.g. there are no such method transitions at all
[12:41] <hjmf> that's why I like to retrace myself
[12:41] <hjmf> I can see the apport warnings
[12:41] <asac> so what do you check?
[12:42] <asac> do you ever abort?
[12:42] <hjmf> the apport stderr for warnings about packages not found
[12:42] <asac> i mean if the stacktrace has valid symbols :)
[12:42] <hjmf> no, I automatically reinstall the right dbg version
[12:42] <asac> "valid looking" actually
[12:42] <hjmf> I match the reporter's firefox version
[12:43] <hjmf> thing that I cannot do with thunderbird
[12:43] <hjmf> as I only have one -dbg
[12:44] <hjmf> I have a good cache pool of old -dbg packages for firefox retraces
[12:44] <hjmf> since we started to retrace
[12:45] <hjmf> so  I can retrace old reports in firefox
[12:45] <hjmf> so those packages that pitty's repo misses by obsolete I still have them
[12:48] <asac> thats fine
[12:49] <asac> hjmf: can you pick two recent ones and look at the code lines
[12:49] <asac> and tell me if they make sense
[12:49] <asac> ... maybe those i rejected where not by you or early ones where maybe some important warnings might have gone unseen
[12:49] <asac> or maybe johns backtrace ... i don't remember
[12:50] <asac> hjmf: the point is that i saw few traces that really made sense
[12:50] <asac> hjmf: and i have the feeling that we probably need to remove some optimization option during build to get good squezes
[12:51] <hjmf> hmm, those confirmed ones that matched upstream bugs looked right
[12:51] <hjmf> I mean, our retraces matched upstream ones
[12:52] <hjmf> asac:  but that is for those I could find the upstream match
[12:54] <asac> hjmf: yes some are valid
[12:54] <asac> i think those that end up in gtk something should be fine
[12:54] <asac> ... at least for the gtk part
[12:55] <asac> how many "mozilla" only traces did you match with upstream?
[12:56] <hjmf> e.g. bug 118287 retraced today
[12:56] <ubotu> Launchpad bug 118287 in firefox "[FEISTY]  firefox crashed [@free]  [@js_FinalizeStringRT]  (dup-of: 71702)" [High,Needs info]  https://launchpad.net/bugs/118287
[12:56] <ubotu> Launchpad bug 71702 in firefox "MASTER Firefox Crash [@js_FinalizeStringRT] [@js_atom_uninterner] " [High,In progress]  https://launchpad.net/bugs/71702
[12:56] <asac> hjmf: ok thats js engine
[12:56] <hjmf> is upstream 267063
[12:56] <asac> js engine might be special case
[12:57] <asac> hjmf: you matched a "layout" crash ?
[12:57] <asac> hjmf: e.g. reflow something
[12:57] <asac> or alike
[12:57] <hjmf> asac: too late to remember those things :)
[12:57] <hjmf> looking
[12:57] <asac> cool
[12:59] <hjmf> hmm, iirc the only upstream bugs I matched are part of those MASTER in state 'in progress'
[01:01] <asac> hmm will look at a few new ones
[01:01] <asac> and look if line numbers make sense
[01:02] <asac> or at least function names make sense :)
[01:02] <hjmf> 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] <hjmf> but almost none have an upstream bug open
[01:03] <asac> hjmf: yeah ... i think that lots of traces make sense
[01:03] <asac> but too many don't make sense
[01:03] <asac> some might not make sense because if things really go bad, the stack is trashed as well
[01:03] <asac> but that should not happen that often imo
[01:03] <asac> though, it might be
[01:04] <hjmf> those are the reports w/o a dup
[01:04] <asac> we talked abit about that on uds
[01:04] <asac> one likely optimization option that might improve the traces would be
[01:04] <asac> -fno-omit-frame-pointer
[01:05] <asac> nobody could really imagine what happends to the backtrace ... and in what specific situation this might cause troubles
[01:05] <asac> hjmf: so what is the bugs w dupe vs bugs wo dupe ration in your opinion?
[01:05] <asac> are they even?
[01:05] <asac> i mean we have heavy weight crashers
[01:06] <asac> like the one i closed (98)
[01:06] <asac> and the ones you know .)
[01:06] <hjmf> I found more dups than non dups
[01:06] <asac> hjmf: thats good at least :)
[01:07] <asac> i think i should do a master bug day soon
[01:07] <hjmf> ?
[01:07] <asac> review all master bugs
[01:07] <asac> and see if they really make sense
[01:07] <hjmf> you mean to close masters?
[01:07] <asac> by looking at code
[01:07] <hjmf> ah!
[01:08] <asac> if they make sense ensure that they are really carried upstream
[01:08] <asac> e.g. if there are talkbacks at least
[01:08] <asac> because unless we see talkbacks for that its likely an ubuntu only issue
[01:08] <asac> and needs to be evaluated further
[01:08] <asac> e.g. maybe its ubuntu only, because we use some other version of libX
[01:08] <asac> or something
[01:09] <asac> or worse: its due to a patch we have :/
[01:09] <hjmf> I did that a couple of weeks ago for those mt-upstream (I was bored)
[01:09] <hjmf> and some I couldn't find references upstream
[01:09] <hjmf> but I don't remmember which ones
[01:10] <hjmf> as I was just only playing a bit
[01:10] <hjmf> :(
[01:10] <asac> hjmf: you said you see that there are talkbacks
[01:10] <asac> if there are tb
[01:10] <asac> can you note the id together with the trace?
[01:10] <asac> then we need to hurry because tb-ids are only valid for some period (e.g. 90 days?)
[01:10] <asac> and post upstream asap
[01:11] <asac> so they can't deny thats their crash :)
[01:11] <hjmf> next time I'll be bored I'll do it :)
[01:11] <asac> ah ... though you automagically search for talkbacks :)
[01:12] <asac> don't need to do that if you do manual
[01:12] <asac> I will post a couple of bug tags ... offer mentoring and then post on forum
[01:12] <asac> the sooner the better
[01:12] <hjmf> cool
[01:12] <asac> one will be upstream triage :), which could exactly be that
[01:13] <asac> or a dedicated MASTER bug Maintainer :)
[01:13] <asac> but i think i dream too much :)
[01:13] <hjmf> :)
[01:13] <hjmf> it's the right hour
[01:13] <asac> right.... :) night!
[01:13] <hjmf> night!
[08:21] <Admiral_Chicago> whats IM_get_context ?
[09:09] <Admiral_Chicago> hey there JenFraggle
[09:15] <Admiral_Chicago> 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] <Admiral_Chicago> JenFraggle: i'll be emailing you shortly however...bed time noe
[09:18] <Admiral_Chicago> now*
[09:19] <JenFraggle> i thought you were up late, it;s 8:20am here
[09:20] <Admiral_Chicago> hehe, it's 2.20 am here
[09:20] <Admiral_Chicago> JenFraggle: where do you live (I ask so i can put a flag on Kworldclock)
[09:20] <JenFraggle> uk
[09:23] <Admiral_Chicago> ah okay.
[09:23] <Admiral_Chicago> ah the UK is all one time zone...
[09:25] <Admiral_Chicago> learned something new just now...
[01:36] <asac> ok i am here ... in case i am needed
[02:12] <asac> i posted a job :)
[02:12] <asac> bug 118482
[02:13] <ubotu> Launchpad bug 118482 in firefox "[JOB]  mozillateam assistant - MASTER bug maintainer" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118482
[02:14] <asac> ok i am off doing something else i pushed back for a while
[03:03] <hjmf> anyone can confirm bug #90410 by reproducing the test case reported by the OP in his last post
[03:03] <ubotu> 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] <hjmf> ty in advance :)
[03:04] <hjmf> asac: cool job request  :)
[03:23] <asac> hjmf: that is dupe
[03:23] <asac> of fat32 issue
[03:23] <asac> i am not sure why it crashes for him
[03:24] <asac> This error cannot be reproduced: Restarting and saving the same email again worked perfectly.
[03:24] <hjmf> asac: the guy says he is able to reproduce it always
[03:24] <asac> crazy
[03:24] <asac> hmm
[03:24] <asac> where do i have a fat32 partition
[03:24] <asac> hmmm
[03:24] <asac> i guess my usb stick has fat16 :(
[03:24] <asac> lets see
[03:25] <asac> hmm its vfat
[03:25] <asac> in mount
[03:25] <asac> hjmf: you know if its the same?
[03:25] <asac> or is vfat really fat 16 :)
[03:26] <asac> ok i will try :)
[03:27] <asac> hjmf: i guess i will rename title [JOB]  [HELP] 
[03:27] <asac> e.g. job sounds too much not-fun :)
[03:27] <asac> hjmf: so any mail?
[03:28] <asac> hmm just saved a mail without crash
[03:29] <asac> maybe vfat is not fat32?
[03:29] <asac> i mean it doesn't even fail
[03:29] <asac> e.g. when using .eml extension nor .txt
[03:30] <hjmf> found so far another related report (with same root cause): bug 92670
[03:30] <asac> hmm ... itersting thing is that .eml really fails ... but without a dialog :)
[03:30] <ubotu> 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] <hjmf> *fails silently* :)
[03:30] <asac> hmm
[03:31] <asac> no it only fails silently when long subject
[03:31] <asac> but lets see i try again with the mail that just failed silently
[03:31] <asac> hmm its not there
[03:31] <asac> but filename starts with [
[03:31] <asac> which might be a problem
[03:31] <asac> though no error message at all
[03:32] <asac> looks like fat really has loads of problems
[03:32] <hjmf> ... 92670 is not a crash as was 90410
[03:33] <hjmf> .. not sure at all if 90410 retrace is good
[03:34] <hjmf> cannot find any related stuff upstream
[03:35] <asac> hmm
[03:35] <asac> maybe "fails silently" is known upstream?
[03:35] <asac> it probably has been posted :)
[03:35] <asac> this does not sound like a bug that is ubuntu specific
[03:36] <hjmf> no, but I started to look for a stack match :)
[03:36] <asac> if its ubuntu only, then its likely the mount options we use for fat by default
[03:36] <asac> dunno if they differ from what other distributions do
[03:36] <hjmf> will look for 'colon', fat32... etc issues
[03:37] <asac> ok i just set the silently bug to mt-upstream
[03:38] <asac> oops did i post my question to the wrong bug?
[03:39] <asac> ah ... missed a reload in another window
[03:39] <asac> ok
[03:48] <hjmf> actually I'm not able to find such upstream bug. I'll resume the search later (noted) :)
[03:53] <asac> bugzilla 374789
[03:53] <asac> bugzilla bug 374789
[03:53] <asac> mozilla bug 374789
[03:54] <ubotu> 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] <asac> mozilla 374789
[03:54] <asac> ok so both
[03:54] <asac> mozilla bug 357493
[03:54] <ubotu> 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
[07:28] <Admiral_Chicago> hmm firefox is not letting me download a file
[07:28] <Admiral_Chicago> this is odd
[07:29] <asac> yeah ... the daily odds
[07:29] <asac> ;)
[07:30] <Admiral_Chicago> ah i see it, i was downloading a massive file into the wrong directory...
[07:36] <asac> hehe
[07:44] <Admiral_Chicago> asac: can you help me at looking at a retrace for bug 113284
[07:44] <ubotu> Launchpad bug 113284 in gimp "[apport]  jpeg crashed with SIGSEGV in _XSetLastRequestRead()" [Medium,Needs info]  https://launchpad.net/bugs/113284
[07:44] <Admiral_Chicago> its a gimpe bug but i'm not sure where the crash was
[07:50] <asac> yes
[07:50] <asac> what is it?
[07:51] <asac> its completely useless
[07:52] <asac> so hoping for more informative valgrind is better
[07:52] <Admiral_Chicago> oh i see
[07:53] <gnomefreak> trunk is borked again
[08:00] <asac> he?
[08:00] <asac> is alpha5 out yet?
[08:00] <asac> hmm not yet
[08:00] <asac> last aggressive landings?
[08:01] <asac> what broke gnomefreak?
[08:01] <gnomefreak> patch it looks like
[08:01] <asac> haha
[08:01] <asac> be more specific please
[08:01] <gnomefreak> im watching it this time
[08:01] <asac> i can assume that a patch broke :)
[08:01] <gnomefreak> Applying patch nspr_macro_backport_for_gfx_thebes
[08:01] <gnomefreak> patching file xpcom/ds/nsExpirationTracker.h
[08:01] <gnomefreak> Hunk #1 FAILED at 35.
[08:01] <gnomefreak> 1 out of 1 hunk FAILED -- rejects in file xpcom/ds/nsExpirationTracker.h
[08:01] <gnomefreak> Patch nspr_macro_backport_for_gfx_thebes does not apply (enforce with -f)
[08:02] <gnomefreak> make: *** [debian/stamp-patched]  Error 1
[08:02] <asac> interesting
[08:02] <asac> did they add it as well?
[08:02] <asac> can you look what is in that file at line 35 (and aroun +-20 lines) and paste it?
[08:02] <gnomefreak> the file not the patch right?
[08:02] <asac> yes
[08:02] <asac> the file
[08:03] <asac> just give me the first 200 lines :)
[08:03] <gnomefreak> give me a few
[08:03] <asac> should be not too expensive ;)
[08:03] <asac> sure
[08:03] <asac> coffee refill anyways
[08:05] <gnomefreak> asac: http://gnomefreak.pastebin.ca/534153
[08:08] <gnomefreak> asac: ignore that one please somethign got messed up
[08:08] <gnomefreak> asac: http://gnomefreak.pastebin.ca/534162
[08:09] <gnomefreak> #ifndef???
[08:09] <asac> hmm
[08:09] <asac> can you fix it?
[08:09] <asac> look at the diff
[08:10] <asac> the #defines added there need to be in that file as well
[08:10] <asac> gnomefreak ... go to build-tree/mozilla
[08:10] <asac> call quilt push -f
[08:10] <asac> then edit xpcom/ds/nsExpirationTracker.h
[08:10] <asac> so there is no conflict anymore
[08:10] <asac> you will figure out
[08:11] <gnomefreak> cant it failed to apply
[08:11] <asac> look at the patch
[08:11] <asac> you can
[08:11] <asac> you can do instructions above
[08:11] <gnomefreak> quilt push -f fails
[08:11] <asac> yes
[08:11] <asac> but now you have the conflict marked in file
[08:11] <asac> xpcom/ds/nsExpirationTracker.h
[08:11] <asac> go in there
[08:11] <asac> fix the conflict
[08:11] <gnomefreak> ah ok
[08:11] <asac> the quilt refresh --diffstat -U8
[08:12] <asac> then you are done
[08:12] <asac> maybe show me the new diff afterwards :)
[08:12] <asac> it can be found in debian/patches/ after "refresh"
[08:12] <gnomefreak> what will make conflict stand out?
[08:12] <asac> nothing you saw it
[08:13] <asac> ah
[08:13] <asac> its <<<<<<
[08:13] <asac> [08:13] <asac> >>>>
[08:13] <asac> usually
[08:13] <asac> you should see those markers
[08:13] <gnomefreak> i wish
[08:16] <gnomefreak> asac: they are not there http://gnomefreak.pastebin.ca/534183
[08:18] <gnomefreak> the #include "prerror.h" is only in .rej file not in .h file
[08:18] <asac> Admiral_Chicago: actually we don't need to request retraces for i386 as hilario will do them anyways :)
[08:18] <gnomefreak> #include "prlog.h" in .h file
[08:19] <asac> yes
[08:19] <asac> you have to add what is in .rej
[08:19] <asac> to .h
[08:19] <asac> its basically an #include
[08:19] <asac> and maybe #define?
[08:19] <gnomefreak> do i take prlog out?
[08:19] <asac> or are defines meerged
[08:19] <asac> why?
[08:19] <gnomefreak> it not in .rej only in reg file
[08:19] <asac> don't drop
[08:20] <gnomefreak> k
[08:20] <asac> as i said
[08:20] <asac> only add
[08:20] <asac> what is in patch
[08:20] <asac> to the reg file
[08:20] <gnomefreak> is #ifndef a typo?
[08:20] <asac> why?
[08:20] <asac> its valid
[08:20] <gnomefreak> k
[08:20] <asac> means ... if not defined
[08:20] <asac> in contrast to
[08:20] <asac> #ifdef  -> if defined
[08:20] <gnomefreak> the patch has #ifndef NSEXPIRATIONTRACKER_H_ #define NSEXPIRATIONTRACKER_H_
[08:21] <gnomefreak> #include "prerror.h"
[08:21] <asac> gnomefreak: no
[08:21] <asac> only what is marked with +
[08:21] <asac> everything else is just unmodified context
[08:21] <asac> so you can better read it
[08:21] <asac> you see the + lines in patch?
[08:21] <asac> that is what is added by patch
[08:21] <asac> if there ar - lines in patch then its removed by patch
[08:21] <gnomefreak> yes
[08:21] <asac> ... so much for patch basics :)
[08:22] <gnomefreak> looking in wrong place needed to be lower :(
[08:22] <gnomefreak> ok let me see here
[08:23] <gnomefreak> the .rej and patch look the same
[08:24] <asac> the same like what?
[08:24] <gnomefreak> like identical
[08:24] <asac> identical compared to what?
[08:24] <gnomefreak> eachother looking at file now
[08:25] <asac> hmmm
[08:25] <asac> you will figure out
[08:25] <gnomefreak> #include "prlog.h" is the only thing not in rej or patch
[08:25] <asac> yes
[08:25] <asac> which is why it failed to apply
[08:25] <asac> because patch command didn't know what to do
[08:26] <asac> so you just have to add what is in patch to the "new" file
[08:26] <gnomefreak> so i have to add that to patch
[08:26] <asac> no
[08:26] <gnomefreak> oh
[08:26] <asac> you apply the patch manually
[08:26] <asac> then run quilte refresh ... to refresh the patch
[08:26] <asac> editing patches by hand is the last step in becoming a patch expert :) ... first understand what patches are doing ,)
[08:26] <gnomefreak> asac: thats backwards
[08:26] <asac> manually
[08:27] <asac> means by editing file
[08:27] <asac> not by patch command
[08:27] <gnomefreak> asac: the file has the include the patch does not
[08:27] <asac> gnomefreak: ignore what the patch has except the + lines
[08:27] <asac> everything else doesn't matter much
[08:27] <gnomefreak> that looks like all comments though
[08:27] <asac> it just serves you to find the place the + lines have to be added
[08:27] <asac> #if... is not a comment
[08:27] <gnomefreak> +/* asac: backported from trunk nspr
[08:27] <asac> nor is #....
[08:27] <asac> those are instructions
[08:27] <gnomefreak> and continues
[08:28] <asac> yes add those comments as well
[08:28] <gnomefreak> +*/
[08:28] <gnomefreak> +#define PR_STATIC_ASSERT
[08:28] <asac> yes
[08:28] <asac> its allright
[08:28] <asac> you have to add *all*
[08:28] <asac> those + lines
[08:28] <gnomefreak> none of the includes have a +
[08:28] <asac> (of course without + in front
[08:29] <asac> gnomefreak: yes ... so don't add any include to the file
[08:29] <asac> only + lines matter
[08:29] <asac> read above
[08:29] <asac> its all in there :)
[08:30] <asac> ;)
[08:31] <asac> yeah ;)
[08:31] <asac> first step is to understand what the .patch file and the .rej file actually means
[08:31] <asac> maybe take a close look
[08:31] <asac> you should be able to guess what they mean
[08:31] <asac> ;)
[08:34] <gnomefreak> what i mean is the patch has things that the file doesnt but there are no + for them
[08:34] <gnomefreak>  #ifndef NSEXPIRATIONTRACKER_H_
[08:34] <gnomefreak>  #define NSEXPIRATIONTRACKER_H_
[08:34] <gnomefreak> 
[08:34] <gnomefreak>  #include "prerror.h"
[08:34] <gnomefreak> +
[08:34] <gnomefreak> the #include line is not in the file itself but the patch
[08:35] <gnomefreak> the + is on its own line than starts the comment area
[08:36] <gnomefreak> same with .rej no + next to #include "prerror.h"
[08:36] <gnomefreak> so i would assume it doesnt get added to file but than why is it in patch
[08:38] <gnomefreak> ok i added all but the #include "prerror.h"
[08:40] <asac> gnomefreak: don't add it
[08:40] <asac> they dropped it intentionally
[08:40] <gnomefreak> 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] <asac> and our patch doesn't need that header afaik
[08:41] <asac> you JUST add changes
[08:41] <gnomefreak> done
[08:41] <asac> OK?
[08:41] <asac> good ... run quilt refresh --diffstat -U8
[08:41] <asac> and paste the new patch for me to review :)
[08:44] <gnomefreak> http://gnomefreak.pastebin.ca/534256
[08:45] <asac> gnomefreak: ok ... let me look at the original one
[08:45] <gnomefreak> lol
[08:46] <gnomefreak> it updated the orig patch
[08:46] <asac> gnomefreak: i added those defined above the other includes
[08:46] <asac> but looks worth a try
[08:47] <asac> just try to build with it
[08:47] <asac> i looked locally for the old
[08:47] <gnomefreak> no more quilt commands just clean and build?
[08:47] <asac> you can even just try
[08:47] <asac> dpkg-buidpackage -rfakeroot -nc
[08:47] <asac> otherwise yes
[08:47] <asac> if you have run quilt refresh then its done
[08:48] <asac> and patch is updated fine
[08:48] <asac> maybe you see why quilt is more handy as dpatch for modifying patches :)
[08:50] <asac> yeah but takes ages :)
[08:50] <gnomefreak> i have gotten used to it sort of for iceape (still have alot to learn with patches
[08:50] <gnomefreak> i agree it is longer
[08:50] <asac> gnomefreak: you should take every chance to look thorougly at patches
[08:51] <asac> and try to match what they do in the file
[08:51] <asac> then apply, look if it does what you expected
[08:51] <asac> unapply again
[08:51] <asac> if you this a few times you will get used to patches pretty fast
[08:51] <asac> :)
[08:51] <gnomefreak> true i have started looking through them but some patches are 10+ files in one patch it gets a bit confusing
[08:52] <asac> yes
[08:52] <asac> start with simple cases
[08:52] <asac> and work up the food chain
[08:53] <gnomefreak> that would be easier
[08:53] <asac> yes ... but the patch you just did is a *really* simple one
[08:53] <asac> not most simplistic, but really tinay
[08:53] <asac> tiny
[08:54] <asac> gnomefreak: actuallyl what you did was a *merge*
[08:54] <asac> next time try to match the line where you add the new lines more carefully
[08:54] <asac> you should have put the lines above the includees
[08:54] <asac> e.g. in our case it might not matter ... but general it can be fatal to move relative position in code of some snippets
[08:54] <asac> :)
[08:55] <gnomefreak> oh cause from the looks of the file it went under because in the patch after that part is the next set of comments that started with data
[08:56] <gnomefreak> #** data
[08:56] <gnomefreak> or something like that
[08:57] <asac> hmm
[08:57] <gnomefreak> if you look at http://gnomefreak.pastebin.ca/534183
[08:57] <asac> next time look harder :)
[08:57] <gnomefreak> than look at patch
[08:57] <asac> whats that
[08:57] <gnomefreak> the file itself
[08:57] <asac> so your new patch didnt apply or what?
[08:57] <gnomefreak> after #include .... you have the comment starting with data
[08:58] <gnomefreak> i think it did
[08:58] <asac> ah ok
[08:58] <asac> yes ... but in patch there is #include lines between it
[08:58] <gnomefreak> ah
[08:58] <asac> if you look at the original patch
[08:58] <asac> you see?
[08:59] <asac> it doesn't matter for us i guess, (unless it fails to build now of course) ... but usually this would have been hard to chew :)
[08:59] <asac> ok ... i feel tough
[08:59] <asac> want to install ati official drivers
[08:59] <asac> do you think it works?
[08:59] <gnomefreak> they suck
[08:59] <asac> the default feisty driver sucks
[08:59] <asac> it freezes system when playing 3d games
[08:59] <asac> like ut2004 quake4
[09:00] <gnomefreak> both suck if you ask me but people said it was easier to install from ati than our drivers
[09:00] <asac> want to try if ati one gives me healing
[09:00] <asac> easier then our?
[09:00] <asac> our is just a package?
[09:00] <asac> lets see what happens
[09:00] <gnomefreak> easier than our package
[09:00] <asac> i have the feeling i will kill my system :)
[09:00] <asac> 51mb download
[09:00] <gnomefreak> backup :)
[09:00] <asac> no ... that would be coward like
[09:01] <gnomefreak> lol
[09:01] <gnomefreak> true
[09:01] <asac> ... and i cannot backup anyway
[09:01] <asac> its far too much things on this system :)
[09:01] <gnomefreak> i see your point
[09:01] <asac> i guess the backup solution would suck $10k
[09:02] <asac> ok ati fun commences
[09:02] <gnomefreak> good luck
[09:03] <asac> i would really like to know what its doing now
[09:03] <asac> does it oeverwrite my /usr hierarchy files?
[09:06] <Admiral_Chicago> asac: sounds good.
[09:10] <gnomefreak> @schedule
[09:10] <ubotu> Schedule for Etc/UTC: 05 Jun 19:00: Technical Board | 06 Jun 20:00: Edubuntu | 07 Jun 20:00: Ubuntu Development Team | 12 Jun 15:00: Kernel Team | 13 Jun 12:00: Edubuntu | 14 Jun 16:00: Ubuntu Development Team
[09:11] <gnomefreak> @schedule new_york
[09:11] <ubotu> Schedule for America/New_York: 05 Jun 15:00: Technical Board | 06 Jun 16:00: Edubuntu | 07 Jun 16:00: Ubuntu Development Team | 12 Jun 11:00: Kernel Team | 13 Jun 08:00: Edubuntu | 14 Jun 12:00: Ubuntu Development Team
[09:11] <gnomefreak> asac: hjmf Admiral_Chicago how does june 12th 1800UTC sound for meeting?
[09:11] <Admiral_Chicago> gnomefreak: works for me
[09:12] <gnomefreak> maybe 1900 (not sure how long to give -devel for htiers
[09:12] <gnomefreak> thiers
[09:12] <Admiral_Chicago> two hours should be enough no
[09:12] <Admiral_Chicago> three would work as well
[09:15] <hjmf> gnomefreak: fine for me too
[09:15] <gnomefreak> ty
[09:18] <gnomefreak> Admiral_Chicago: if you think jen is ok to go for membership to mozillateam please have him/her add info to meetings wiki (theres now a place for new memberships
[09:18] <gnomefreak> )
[09:19] <gnomefreak> happy either way not restricting to just cluefiles
[09:46] <Admiral_Chicago> gnomefreak: i saw that, i'll have to talk to her at our next discussion
[09:46] <asac> it doesn't work
[09:46] <asac> now all direct rendering is gone
[09:46] <asac> :(
[09:47] <asac> how did jen contribute? bughelper?
[09:47] <asac> can we go 1700 UTC or is that too erly?
[09:47] <gnomefreak> been working with Admiral_Chicago everyday from what ive seen
[09:47] <Admiral_Chicago> asac: yes, she has been working on clue files.
[09:47] <gnomefreak> asac: devel meeting than
[09:47] <Admiral_Chicago> gnomefreak asac actually we do a lot of work in PMs
[09:47] <asac> y
[09:48] <Admiral_Chicago> so i brought her up to speed on the project and she has been doing good work
[09:48] <Admiral_Chicago> asac: i think she prefers to do it that way.
[09:48] <asac> yes ... but she doesn't need to be shy ;)
[09:49] <asac> showing ignorance is not a problem :)
[09:49] <gnomefreak> this is bad
[09:49] <gnomefreak> very very bad
[09:50] <Admiral_Chicago> well either way, I have quite a few logs of her and I discussing clue files.
[09:50] <asac> Admiral_Chicago: i believe you :-D
[09:50] <asac> don't need to see any logs
[09:50] <asac> if you say she has proven constance in contributing then she can go in
[09:50] <Admiral_Chicago> asac: :) after we finish the firefox one, we are going to add thunderbird, gnash, all of the other ones
[09:51] <asac> all of the other ones?
[09:51] <asac> so for 9000 packages?
[09:51] <Admiral_Chicago> yes.
[09:51] <asac> i think we need innovation here ;)
[09:51] <Admiral_Chicago> no for all the other Mozilla related packages.
[09:51] <asac> k
[09:51] <asac> Admiral_Chicago: actually on the long run most crashers don't need to be detected by clue files
[09:52] <asac> we have to find a way to track other duplicates
[09:52] <asac> Admiral_Chicago: you have any idea how to do that?
[09:52] <Admiral_Chicago> gnomefreak: i think they would.
[09:52] <Admiral_Chicago> asac: to find other duplicates of what?
[09:52] <gnomefreak> i hope so
[09:53] <Admiral_Chicago> i don't think i understand, bughelper and clue files seem like a good way to find duplicates of crashes...
[09:53] <Admiral_Chicago> gnomefreak: what kind of cord?
[09:53] <gnomefreak> the one from caera to USB port
[09:53] <Admiral_Chicago> gnomefreak: yep, I have seen them on sale.
[09:53] <gnomefreak> goodie
[09:53] <Admiral_Chicago> like miniUSB to computer USB
[09:54] <gnomefreak> yes
[09:54] <asac> Admiral_Chicago: there will be crash auto dupe detection at some point
[09:54] <gnomefreak> sort of its more like mini printer port on one end
[09:55] <Admiral_Chicago> yep, I have seen them at the store. circuit city or radioshack or best buy should carry them
[09:55] <gnomefreak> ill call target see if they have one cheap little later
[09:56] <Admiral_Chicago> asac: thats good, but i still don't think i understand. crash will be auto tagged. are you asking about other duplicates (non crashes?)
[09:57] <asac> yeah
[09:57] <asac> i am wondering if we can find some scheme on how to find "likely" dupes
[09:57] <asac> dupes
[09:57] <asac> e.g. some heuristic
[09:57] <asac> maybe through some categorization of bugs
[09:57] <Admiral_Chicago> thats something i'd have to think about
[09:58] <asac> imo it won't work to find 100% duplicates
[09:58] <asac> just reduce the set of bugs you actually have to look at in order to judge whether there is a dupe or not
[09:58] <asac> maybe we should try to take a list of "non" crash bugs and look ;)
[09:58] <asac> but i guess one has to chew on this
[09:59] <Admiral_Chicago> asac: what do you think about bug 117260
[09:59] <ubotu> Launchpad bug 117260 in firefox ""Save to Disk" confuses some users" [Wishlist,Confirmed]  https://launchpad.net/bugs/117260
[10:00] <asac> yeah
[10:00] <asac> i can't tell
[10:00] <asac> do you want to take care for that bug upstream?
[10:00] <asac> i mean thats something upstream has to decide
[10:00] <asac> you can look if there is already such a bug
[10:00] <asac> and if not, tell me
[10:00] <Admiral_Chicago> if there was a way to handle crashes much more automatically, it will free us up a lot more work with other
[10:00] <Admiral_Chicago> yes, that was my flow of thinking
[10:00] <asac> aeh open a new bug and tell me so i can confirm that bug in bugzilla
[10:01] <asac> Admiral_Chicago: yes right
[10:01] <Admiral_Chicago> asac: QG brought it to my attention
[10:01] <asac> i already read about that bug
[10:01] <asac> but couldn't deal with it so far
[10:01] <asac> is it mt-upstream?
[10:01] <Admiral_Chicago> it seems like its a UI issue which could be worked out by Fx 3
[10:01] <Admiral_Chicago> no
[10:02] <asac> ok set to mt-upstream
[10:02] <asac> feel free to take it
[10:02] <Admiral_Chicago> will do
[10:02] <asac> just look if upstream has a bug, otherwise post it as an enhancement bug and tell me
[10:02] <asac> then lets see what upstream says
[10:02] <Admiral_Chicago> QG: this is really a bug that we need to discuss with the Mozilla Foundation, it is there call really.
[10:03] <asac> i think they will deny it, but maybe they will come up with something
[10:03] <asac> yes
[10:03] <Admiral_Chicago> QG: I will look for a bug in their bug tracker, if there is one we will track it, if not i will file it.
[10:03] <asac> if QG wants to do upstream communication then i am fine as well :)
[10:03] <asac> just tell me the bug so i can confirm
[10:04] <asac> which will raise likelyhood that someone will actually look at it
[10:04] <asac> ... someone who matters
[10:04] <Admiral_Chicago> yea looking now...
[10:05] <QG> does '...upstream communication...' mean the same as filing a bug in Mozila's bugtracker?
[10:05] <asac> yes ... first figuring out for sure that there is no duplicate
[10:05] <asac> if that is done filing upstream
[10:05] <asac> and arguing ... trying to find a solution
[10:05] <asac> in case there is discussion happening
[10:06] <asac> giving good suggestions can help ... but don't guarantee success
[10:06] <asac> UI changes usually take ages at firefox
[10:06] <Admiral_Chicago> QG: upstream really means looking for it at the higher source of the package. be it debian, the actual maintainer of the bug report...
[10:07] <asac> DG upstream communication also means pinging the bug every few month
[10:07] <asac> so people might not forget :)
[10:07] <Admiral_Chicago> asac: this is seen a bit upstream so you are in luck QG i think
[10:07] <QG> If a similar bug exists, or we file a new one upstream, then do we close the Ubuntu one in Launchpad?
[10:08] <asac> no we set it to in progress
[10:08] <asac> after setting upstream target
[10:08] <asac> but not before the bug is confirmed
[10:08] <asac> upsream
[10:08] <Admiral_Chicago> asac: https://bugzilla.mozilla.org/show_bug.cgi?id=301972 this one?
[10:08] <ubotu> Mozilla bug 301972 in Download Manager ""Save to Disk" option needs to be more clear" [Trivial,New] 
[10:08] <asac> yeah ... the title looks like it :)
[10:09] <asac> yeah ... looks like
[10:09] <asac> mark it ... lets move on
[10:09] <asac> its confirmed and upstream is chewing on it i guess :)
[10:09] <Admiral_Chicago> i'll mark it up..
[10:10] <QG> yes, I read it and it's the same one. What good luck!
[10:11] <QG> How do I 'ping' the bug in practice. Is that like posting a new comment every once in a while so that the bug contacts get reminded?
[10:12] <Admiral_Chicago> QG: exactly
[10:13] <QG> OK. So I can go ahead and change the status in Launchpad to 'in progress'?
[10:13] <Admiral_Chicago> no
[10:14] <Admiral_Chicago> well it would be in progress if it is in progress upstream
[10:14] <Admiral_Chicago> it would be confirmed
[10:14] <QG> Ahhh, only once it's in progress upstream. I see
[10:15] <QG> what does the red horizontal line mean in Xchat?
[10:15] <Admiral_Chicago> no idea...i use irssi
[10:17] <QG> question: what's the benefit of having 2 open bugs about the same thing; one in Launchpad and another in Mozilla bugtracker. Can't we close the Launchpad one and refer everyone to the Mozilla one. That would make one less redundant bug in Launchpad wouldn't it?
[10:18] <Admiral_Chicago> QG: not really. there are instances were it is fixed upstream but not in the release which is was filed in.
[10:19] <QG> hmmm...
[10:19] <Admiral_Chicago> for example if inkscape releases a version (1.6.5.2) which fixed a bug but I am using Dapper and use 1.6.3.0, i would like to know the bug is fixed upsream
[10:19] <Admiral_Chicago> upstream*
[10:19] <Admiral_Chicago> so i would know that i could compile from source and get the bug fixed
[10:20] <gnomefreak> once fixed upstream we either have to take new upstream package and build or apply patch (normally apply patch unless there are multiple fixes upstream)
[10:20] <QG> I understand better now. thank you for the clarification
[10:22] <QG> so to test my understanding, once It is fixed upstream, and I am sure that someone is updating the particular release version to move the fix downstream then I would change the status to 'in progress'?
[10:27] <QG> in future, how do i add the upstream link to the Launchpad entry so that it shows up like it does for this bug? Do I need to have special rights to do so?
[10:29] <Admiral_Chicago> QG: look at the side, it'll say affects upstream in launchpad
[10:30] <QG> got it. thanks
[10:31] <asac> QG: once the bug is upstream and you are sure that upstream somehow cares fr it  it would be "in progress"
[10:31] <asac> for us :)
[10:31] <asac> that is probably mozillateam specific
[10:32] <asac>  bug 117260
[10:32] <ubotu> Launchpad bug 117260 in firefox ""Save to Disk" confuses some users" [Wishlist,Confirmed]  https://launchpad.net/bugs/117260
[10:33] <asac> i am here
[10:33] <asac> but not for much longer
[10:33] <asac> almost gone
[10:33] <QG> this was my BugSquad learning nugget for today. Thanks Admiral_Chicago, asac, gnomefreak et. al. Goodnight and hasta luego
[10:34] <gnomefreak> nsNSSComponent.cpp: In function void setOCSPOptions(nsIPrefBranch*):
[10:34] <gnomefreak> nsNSSComponent.cpp:998: error: ocspMode_FailureIsVerificationFailure was not declared in this scope
[10:34] <gnomefreak> nsNSSComponent.cpp:998: error: CERT_SetOCSPFailureMode was not declared in this scope
[10:34] <asac> gnomefreak: stop
[10:34] <gnomefreak> nsNSSComponent.cpp:1001: error: ocspMode_FailureIsNotAVerificationFailure was not declared in this scope
[10:34] <gnomefreak> nsNSSComponent.cpp:1001: error: CERT_SetOCSPFailureMode was not declared in this scope
[10:34] <asac> paste with lots of context somewhere
[10:34] <gnomefreak> asac: for the most part that is the errors
[10:35] <gnomefreak> how far back?
[10:35] <asac> when the error starts
[10:35] <gnomefreak> k
[10:35] <asac> its definitly further above then what you posted
[10:36] <gnomefreak> http://gnomefreak.pastebin.ca/534617 asac
[10:36] <asac> hatre
[10:37] <gnomefreak> looks like has something to do with nss
[10:37] <asac> yeah
[10:37] <asac> our system nss is now too old
[10:37] <gnomefreak> omg
[10:37] <asac> thje patch you fixed try to workaround this once
[10:37] <asac> but now it looks it doesn't help, but we need libnss-trunk
[10:37] <asac> or something
[10:38] <gnomefreak> we will also need nspr too?
[10:38] <asac> unfortunatle
[10:38] <asac> probably
[10:38] <asac> maybe not now
[10:38] <asac> but if they change something in nspr, then probably because there is immediate need on firefox-trunk
[10:38] <gnomefreak> that is gonna mean everything has to be rebuilt around new nss
[10:38] <asac> no
[10:38] <gnomefreak> oh good
[10:38] <asac> that new package would be just for firefox-trunk
[10:39] <asac> we could try for fun to build epiphany with trunk gecko engine
[10:39] <asac> :)
[10:39] <asac> unfortunately they landed this right before alpha5
[10:39] <asac> i planned to release firefox-preview package based on alpha5
[10:39] <asac> so we need to fix this first now :)
[10:39] <gnomefreak> yep
[10:39] <asac> or don't use system nspr
[10:40] <asac> i will think about it
[10:40] <gnomefreak> in gutsy we have to no?
[10:40] <asac> maybe we will go with embedded libnspr/nss first
[10:40] <asac> and move to system libs when we want another app from trunk
[10:40] <asac> i think we should just build without system nss and nspr
[10:40] <asac> gnomefreak: can you try if it builds if you do that in rules?
[10:41] <asac> would be good to know that there is no other problem :)
[10:41] <gnomefreak> yep, can try
[10:41] <asac> cool
[10:42] <gnomefreak> looking for it atm
[10:42] <gnomefreak> without or pull them out
[10:43] <gnomefreak> --without-system  i think ill try
[10:43] <asac> is it enable-system-nss  or with-system-nss?
[10:43] <gnomefreak> with
[10:43] <asac> yeah then without is right
[10:43] <gnomefreak> i used without on both nspr and nss
[10:43] <asac> sure
[10:43] <gnomefreak> no need to regen tar right?
[10:43] <asac> why?
[10:44] <asac> obviously no need :)
[10:44] <gnomefreak> just making sure
[10:44] <asac> not needed
[10:44] <gnomefreak> im not sure what files after editing matter
[10:45] <asac> in general you never have to regen
[10:45] <asac> unless you change something at regen code :)
[10:45] <gnomefreak> ah
[10:45] <asac> or want new upstream version of course .)
[10:46] <asac> yeah for 2 hours :)
[10:46] <gnomefreak> ill let you know in morning what happens. im goin gto eat dinner
[10:46] <asac> sure
[10:46] <asac> bon appetite
[10:46] <gnomefreak> ty