[02:02] <gnomefreak> this fucking sucks
[02:58] <asac> i am out
[02:58] <gnomefreak> yeah me to
[08:05] <hjmf_> morning!
[10:47] <asac_> morning ... anyone has encrypted wifi?
[10:48] <jerome_> yep
[10:50] <Admiral_Chicago> asac_: i do, not on gutsy though
[10:50] <Admiral_Chicago> sitting with a lappy right next to me on WEP
[10:51] <asac> Admiral_Chicago: thanks ... but i need gutsy
[10:51] <DarkMageZ> Admiral_Chicago, wep ftl
[10:51] <asac> jerome_: you are on gutsy?
[10:52] <jerome_> asac : no
[10:52] <asac> :(
[10:52] <jerome_> sorry :)
[10:52] <asac> np
[10:54] <Admiral_Chicago> DarkMageZ: whats wrong with WEP?
[10:55] <DarkMageZ> Admiral_Chicago, it's a highly broken encryption setup... infact. it's the most broken encryption method ever used.
[10:55] <Admiral_Chicago> what should I use WAP?
[10:55] <Admiral_Chicago> whatever that is called
[10:55] <DarkMageZ> wpa? yes
[10:56] <DarkMageZ> wep = 2-50minutes
[10:56] <asac> bug 121228
[10:56] <ubotu> Launchpad bug 121228 in network-manager "[gutsy]  segfault retrieving passphrase for WiFi network" [High,Confirmed]  https://launchpad.net/bugs/121228
[10:56] <asac> is my concern atm
[10:56] <DarkMageZ> wpa (with a semi-smart key) = 1week-200years.
[10:57] <Admiral_Chicago> DarkMageZ: i'm an idiot and forgot the login name to my router so i can't change it now
[10:57] <Admiral_Chicago> i'll change it soon, thanks for the tip
[11:00] <DarkMageZ> Admiral_Chicago, i'd be reviewing any authentication logs your access point has been keeping.
[11:00] <asac> Admiral_Chicago: night
[12:28] <bluekuja> asac: hrya
[12:28] <bluekuja> *heya
[12:54] <bluekuja> asac: leaving for work
[12:54] <bluekuja> will you be here later?
[02:28] <jerome_> hello
[02:28] <jerome_> i've just started to triage firefox bugs
[02:28] <jerome_> i'm starting with bug 122539
[02:28] <ubotu> Launchpad bug 122539 in firefox "firefox-bin crashed with SIGSEGV" [Undecided,Invalid]  https://launchpad.net/bugs/122539
[02:29] <jerome_> if the report has no stacktrace/backtrace...
[02:29] <jerome_> and if it's a random crash
[02:30] <jerome_> we should close it ?
[02:36] <asac> its already invalid :)
[02:36] <asac> probably i was faster :)
[02:36] <asac> jerome_: ^^^
[02:36] <asac> but otherwise yes ... close and ask reporter to resubmit next time he has a crash
[02:36] <jerome_> asac : ok :)
[02:37] <asac> jerome_: are you going through New bugs?
[02:37] <asac> fine
[02:37] <asac> how many New bugs do we have atm?
[02:37] <jerome_> granparadiso -> 2
[02:37] <jerome_> firefox -> 15
[02:38] <asac> good ... not that bad :)
[02:38] <jerome_> thunderbird -> 26
[02:38] <asac> jerome_: ah ... for crashes we fix summary right from the beginning because we had lots of triagers marking bugs dupes that aren't
[02:38] <asac> e.g. its always firefox-bin crashed with SIGSEGV i summary
[02:38] <asac> so we make [gutsy]  firefox crashed out of it
[02:39] <asac> and tag mt-needsummary
[02:39] <jerome_> ok
[02:39] <asac> or [feisty]  ... or whatever
[02:39] <asac> :)
[02:39] <jerome_> for example let's take bug #122525
[02:39] <ubotu> Launchpad bug 122525 in firefox-granparadiso "firefox-granparadiso-bin crashed with SIGSEGV in __kernel_vsyscall()" [Undecided,New]  https://launchpad.net/bugs/122525
[02:39] <jerome_> the backtrace is full of ???
[02:39] <jerome_> so i put mt-needreport and mt-needtestcase
[02:39] <asac> yeah same for latest firefox submissions
[02:40] <jerome_> and ask for a backtrace with debug symbols on ?
[02:40] <asac> auto-retracers appear to just yield garbage for us
[02:40] <asac> jerome_: no ... lets wait what hjmf_ can get
[02:40] <jerome_> ok
[02:40] <jerome_> you have your own retracer ?
[02:40] <asac> he usually can produce good retraces where auto-retracers fail
[02:40] <jerome_> ok
[02:41] <asac> hjmf_: somehow ... we had auto-retracers before they were setup
[02:41] <jerome_> so just needtestcase ?
[02:41] <asac> for now its mt-needretrace
[02:41] <jerome_> and to testcase ?
[02:41] <asac> as it need retrace try by mozillateam member
[02:41] <asac> you can tag as mt-needtestcase ... but usally we don't do that before we have a good retrace
[02:41] <jerome_> ok
[02:41] <asac> because we deliberately reject bugs without usable trace anyway
[02:42] <asac> you can drop info that reporter may reopen if he can reproduce and provide step-by-step instruction though
[02:42] <asac> but if retracers fail ... tag mt-needretrace first and wait what hjmf_ can do
[02:42] <jerome_> ok
[02:42] <jerome_> done :)
[02:43] <asac> jerome_: great!
[02:43] <jerome_> hard to change habits...
[02:43] <asac> hjmf_: can you see if we get better results for bug 122393 and bug 122525
[02:43] <ubotu> Launchpad bug 122393 in firefox "firefox-bin crashed with SIGSEGV in raise()" [Undecided,Invalid]  https://launchpad.net/bugs/122393
[02:43] <ubotu> Launchpad bug 122525 in firefox-granparadiso "firefox-granparadiso-bin crashed with SIGSEGV in __kernel_vsyscall()" [Undecided,New]  https://launchpad.net/bugs/122525
[02:44] <jerome_> and I bump the LP status to incomplete or just leave it to new ?
[02:44] <asac> jerome_: incomplete
[02:44] <jerome_> asac : ok
[02:44] <asac> as soon as you did something its always incomplete
[02:44] <jerome_> ok
[02:44] <jerome_> asac : and for importance you have a different scale ? Or it's the normal one ?
[02:45] <asac> so retitle bug 122525 '[gutsy]  firefox-granparadiso crashed'
[02:45] <ubotu> Launchpad bug 122525 in firefox-granparadiso "firefox-granparadiso-bin crashed with SIGSEGV in __kernel_vsyscall()" [Undecided,New]  https://launchpad.net/bugs/122525
[02:45] <asac> jerome_: we used to set all crashers to High
[02:45] <asac> but i am reconsidering this atm
[02:45] <jerome_> asac : so I put it on high until then ?
[02:46] <asac> jerome_: yes
[02:46] <jerome_> asac : ok !
[02:46] <jerome_> thx
[02:47] <asac> np
[02:54] <asac> gnomefreak: can you subscribe mozilla-bugs to firefox-granparadiso bugs?
[03:17] <asac> hjmf_: maybe we miss loads of dupes of bug 14911
[03:17] <ubotu> Launchpad bug 14911 in firefox "Flash plugin problem with ARGB visuals causes crash" [Medium,In progress]  https://launchpad.net/bugs/14911
[03:17] <asac> we somehow don't have a retrace
[03:17] <asac> hjmf_: looking at dupe list ... it stopped at bug-id 77k ... but i don't think this issue is fixed
[03:47] <asac> mozilla bug 343747
[03:47] <ubotu> Mozilla bug 343747 in History "bfcache should only cache documents where the channel implements nsICachingChannel" [Normal,Unconfirmed]  http://bugzilla.mozilla.org/show_bug.cgi?id=343747
 hjmf_: maybe we miss loads of dupes of bug 14911
 Launchpad bug 14911 in firefox "Flash plugin problem with ARGB visuals causes crash" [Medium,In progress]  https://launchpad.net/bugs/14911
 we somehow don't have a retrace
[04:04] <ubotu> Launchpad bug 14911 in firefox "Flash plugin problem with ARGB visuals causes crash" [Medium,In progress]  https://launchpad.net/bugs/14911
[04:04] <ubotu> Launchpad bug 14911 in firefox "Flash plugin problem with ARGB visuals causes crash" [Medium,In progress]  https://launchpad.net/bugs/14911
[04:04] <hjmf> hmm, I might be able to retrace the last report attached which seems to be from edgy in the hope that shows something useful...
[04:05] <hjmf> but not the others as look to be from dapper
[04:07] <hjmf> asac: do we have -dbg or -dbgsym for firefox-granparadiso?
[04:07] <hjmf> it seems not
[04:11] <asac> hjmf: yes there should be
[04:11] <asac> in pittis repo
[04:11] <asac> at least we have for latest firefox
[04:11] <hjmf> looking
[04:17] <hjmf> uha! I had a full system crash
[04:17] <hjmf> maybe something wrong on my gutsy chroot caused it :S
[04:20] <asac> oh
[04:20] <asac> hardware issue?
[04:20] <hjmf> I hope not
[04:21] <hjmf> I was doing two retraces one on gutsy and the other on edgy
[04:21] <hjmf> I think I'm going to rebuild my gutsy chroot
[04:21] <asac> system should not be crashable by user-space
[04:21] <asac> so most likely driver issue?
[04:21] <hjmf> mmm
[04:21] <asac> or memory problem :)
[04:22] <asac> or hard-disk
[04:22] <asac> do you see anything in messages?
[04:23] <asac> hjmf_: i talked with pitti about improving auto-dupe marking
[04:23] <hjmf> yes
[04:23] <asac> he is fine with adding a feature that allows us to manually merge in initial crashes
[04:23] <asac> to existing dupe clusters ... so we don't need to remaster everything
[04:23] <hjmf> cool
[04:24] <asac> only change needed is to look if bug that is found as master in crashdb is marked as duplicate
[04:24] <asac> and then use the real master to merge in new bug
[04:25] <asac> hjmf_: so retrace of Cc: Bryce Harrington <bryce@ubuntu.com>,                                         Alexander Sack <asac@canonical.com>, tim.gardner@canonical.com,          amit.kucheria@canonical.com, Colin Watson <cjwatson@ubuntu.com>,         Ben Collins <bcollins@ubuntu.com>
[04:25] <asac> ups
[04:25] <asac> :)
[04:25] <hjmf> :)
[04:32] <asac> hmm offline
[04:32] <asac> i hate this provider
[04:32] <asac> today is really a bad day
[04:33] <asac> haven't received anything for last 10 min or so
[04:34] <asac> hjmf_: anyway ... i think the change should be done in apport/crashdb_impl/launchpad.py:319
[04:35] <asac> currently there is just bug.mark_duplicate(master)
[04:35] <asac> which is the master found in crashdb
[04:35] <asac> so how can i find if master is marked as duplicate to use that accordingly?
[04:35] <asac> btw, the bzr branch i am looking at is: http://bazaar.launchpad.net/~ubuntu-core-dev/apport/ubuntu/
[04:36] <hjmf> looking
[04:36] <asac> oh its line 257
[04:36] <asac> hjmf_: http://paste.ubuntu-nl.org/27432/
[04:36] <asac> thats the code
[04:36] <asac> i guess
[04:37] <asac> maybe we need to do something about mark_regression as well
[04:38] <asac> but unsure
[04:40] <hjmf> that code is just to mark a bug duplicate of another
[04:40] <hjmf> as  I have something similar in my scripts
[04:40] <hjmf> we need something to change the master if is that what I understand?
[04:42] <asac> hjmf_: no
[04:42] <hjmf> ... maybe I'm lost
[04:42] <asac> the idea is to look if master is 'not a master', but is already a child of another master
[04:42] <asac> e.g. is master marked as duplicate of #xxxx
[04:42] <asac> then use #xxxx instead
[04:42] <hjmf> yes, that's what i meant
[04:42] <hjmf> :)
[04:42] <asac> ah
[04:43] <hjmf> when I said change master of the one that apport sees
[04:43] <asac> yes right ... e.g. bug.mark_duplicate(new_master) :)
[04:44] <asac> with new_master = master.has_master() ? master.get_master() : master
[04:44] <asac> ;)
[04:44] <asac> does python allow ? : ?
[04:44] <hjmf> yes, but I'm not sure if that is the piece of code to look
[04:44] <asac> why not?
[04:44] <asac> its the place that apport calls if he finds a master in its crashdb
[04:44] <asac> so we can always look if there is a master
[04:45] <asac> i don't think we should add the new master to db
[04:45] <hjmf> because bug.mark_duplicate(master.bugnumber)
[04:45] <hjmf> its the place where a bug is marked as dup of a master
[04:45] <hjmf> where the master is already knonw
[04:45] <asac> right
[04:45] <asac> sure
[04:45] <hjmf> known
[04:45] <asac> you can probably do it on higher level
[04:46] <asac> just an initial idea :)
[04:46] <hjmf> we need to find where/how are the masters set
[04:46] <asac> probably in apport/crashdb.py
[04:46] <hjmf> as masters
[04:46] <asac> he?
[04:46] <hjmf> looking
[04:46] <asac> look apport/crashdb.py:142
[04:47] <asac> which looks a bit broken btw
[04:47] <asac> e.g. the else: is somewhere in the limbo
[04:47] <hjmf> hmm looking
[04:48] <asac> hjmf_: but i really think launchpad.py is the right place as this feature is launchpad specific
[04:48] <asac> it deals with the special constraint of launchpad that you cannot merge into a non-master
[04:48] <asac> which (might) work in other bts
[04:49] <hjmf> I think I have a different repo, downloading again
[04:52] <hjmf> maybe what we look is at   check_duplicate() in crashdb.py
[04:52] <hjmf> seems that if not finds a master it adds a new one
[04:52] <asac> hjmf_: yes thats all ok
[04:52] <asac> i mean its just ment to support already existing master bugs
[04:52] <asac> that are not in crashdb
[04:55] <asac> i think if we add it to check_duplicate we need an astract method in crashdb: lookup_dupe
[04:55] <asac> and recusively invoke that after we found the bugid in crashdb
[04:55] <asac> yeah ... but take a look :)
[04:56] <asac> i stop now ;)
[04:56] <hjmf> I'll take a look
[04:56] <hjmf> :)
[04:57] <asac> by bet is: simple fix in close_duplicate ... real fix: provide abstract method in crashdb to traverse duplicate up and implement that method in launchpad.py properly
[04:57] <asac> :)
[04:57] <asac> if the real fix is worth the efford depends how launchpad independent the rest of the code is
[04:59] <asac> hmm baby appears to upload new gnash every minute
[05:00] <asac> apparently she does daily cvs snapshots from a stable cvs branch :-P
[05:01] <asac> how senseless ;)
[05:01] <hjmf> asac: do you know from when is the db filled up?
[05:02] <hjmf> s/from/since
 yes right ... e.g. bug.mark_duplicate(new_master)
[05:03] <hjmf> after all you were right :)
[05:04] <hjmf> calling that will be enough as the new_master has a low id, and will be taken as the oldest report
[05:05] <hjmf> let's say our master is bugVeryOld
[05:06] <hjmf> so def close_duplicate(self, bugVeryOld.bugnumber, master):
[05:07] <hjmf> ... never mind, I'll have to look deeper how it works
[05:07] <hjmf> :)
[05:07] <hjmf> I'm too tired now
[05:07] <hjmf> let's have some lunch
[05:07] <asac_> aaaaaahhhhh
[05:07] <asac_> gimme a bomb
[05:07] <hjmf> asac_ you haven't read my stuff
[05:07] <asac_> probably not
[05:07] <hjmf> asac_ better
[05:07] <hjmf> :)
[05:07] <asac_> last message is 10 min ago
[05:08] <asac_> :)
[05:08] <asac_> hehe
[05:08] <asac_> just kiddin
[05:08] <hjmf> then <disclaimer> I'm too tired to read pitti's code </disclaimer>
[05:08] <hjmf> :-P
[05:10] <asac_> k ;)
[05:10] <asac_> good appetite
[05:11] <hjmf> asac_ before I go off
[05:11] <hjmf> asac: do you know since when is the db filled up?
[05:11] <asac_> since a few days ... shouldn't matter for our case though ;)
[05:12] <asac_> unfortunately retraces are broken for us
[05:12] <hjmf> yes
[05:12] <asac_> which is why i wondered if you get better ones
[05:12] <asac_> (pitti mentioned that it might be a new bug in latest apport)
[05:12] <asac_> e.g. on granparadiso bug above
[05:12] <asac_> or my testbug from yesterday
[05:12] <hjmf> yes a couple have resubmitted the full crash reports w/o coredumps
[05:13] <hjmf> ok, I'll try them later
[05:13] <hjmf> off for a while :)
[05:13] <asac_> cool cu
[05:13] <asac_> i will probably be here
[05:13] <asac_> might be out for sport a few hours
[05:13] <hjmf> that's good
[05:13] <hjmf> cu
[05:14] <asac_> but that is still not sure ... if the rain doesn' stop here I won't move a meter
[05:14] <asac_> its 12C :(
[05:14] <gnomefreak> asac_: subscribing now
[05:14] <asac_> on Jun 27
[05:14] <asac_> what a sad thing
[05:14] <gnomefreak> soon as i find it
[05:14] <asac_> gnomefreak: great
[05:16] <gnomefreak> theres already bugs on it
[05:17] <asac_> yes
[05:17] <gnomefreak> done
[05:17] <asac_> which is my i noticed that i don't receive mails
[05:17] <asac_> thanks!
[05:18] <gnomefreak> yw
[05:18] <gnomefreak> any other new packages need to be done while im in here
[05:20] <asac_> not that i know of
[05:20] <asac_> is alpha6 out yet?
[05:20] <asac_> should be coming soon i guess
[05:20] <gnomefreak> not sure yet i will let you know later this afternoon i have alot of house work to try and get done today
[05:21] <gnomefreak> brb reboot
[05:28] <asac_> am i back?
[05:28] <asac_> apparently
[05:28] <asac_> no fun today
[06:19] <kj[] > hi
[06:19] <kj[] > does anyone know how to have thunderbird show the message size of big messages in MB instead of KB?
[06:26] <bluekuja> asac; back
[06:26] <bluekuja> asac: how its going?
[06:29] <asac> yeah ... i will finish soon
[06:29] <asac> not my day today
[06:29] <asac> interenet connection dropped about 10 times today
[06:30] <bluekuja> asac: gonna post the mail soon
[06:30] <bluekuja> can you wait for that?
[06:30] <bluekuja> :)
[06:30] <asac> no idea
[06:30] <asac> :)
[06:31] <bluekuja> asac: I hope so, it's something really important for me, you know :)
[06:31] <asac> bluekuja: discussion will probably take more than 2 minutes
[06:31] <bluekuja> lol
[06:31] <asac> i don't expect that they need my comment today
[06:32] <bluekuja> I know :)
[07:29] <hjmf> asac: I was trying to retrace your crash report, that one on gutsy and I get this gdb error "Failed to read a valid object file image from memory"
[07:30] <hjmf> ... so I'm not able to get a much better retrace than the one from apport retracing service
[07:34] <asac> hmm
[07:34] <asac> interesting
[07:35] <hjmf> I can attach the gdb.log if you want to check it
[07:58] <asac> hjmf:  dbgsym packages installed?
[07:58] <asac> hjmf: do you get a readable backtrace if you run firefox -g
[07:58] <hjmf> yep all of them
[07:58] <asac> and then at some point hit ctrl-z (halt)
[07:58] <asac> then type bt ?
[07:58] <hjmf> asac: yes I've just retrace the granparadiso crash
[07:59] <hjmf> asac: I'm going to try
[08:02] <hjmf> asac: tested, backtrace with good symbols
[08:02] <hjmf> with firefox-2.0.0.4...-dbsym
[08:03] <hjmf> dbgsym
[08:04] <asac> hmm ... so the coredumps are still borked
[08:04] <asac> hmm
[08:04] <asac> damn thing
[08:05] <asac> i think i will upload with -fno-omit-framepointer (anti-optimization)
[08:05] <asac> as soon as tribe-2 is out
[08:05] <asac> just to see if it helps of us
[08:07] <hjmf> asac: bug 122525
[08:07] <ubotu> Launchpad bug 122525 in firefox-granparadiso "[GUTSY]  firefox-granparadiso crashed [@??]  [@~nsCOMPtr_base]  [@~nsHttpTransaction] " [High,Incomplete]  https://launchpad.net/bugs/122525
[08:07] <hjmf> I was able to get a good backtrace
[08:08] <hjmf> despite I still have to set up my machinery for gutsy as I never thought I was going to use it
[08:09] <asac> you have to setup (future) or had (past) ?
[08:10] <asac> hjmf:  that crash is due to incompatible extension
[08:10] <hjmf> i think so
[08:10] <asac> if extension works with our 2.0 package
[08:11] <hjmf> I have to setup future :)
[08:11] <hjmf> I trusted in apport retracing service for gutsy
[08:11] <hjmf> :)
[08:19] <hjmf> we are not getting granparaiso bugmail in ubuntumozilla-team-bugs, are we?
[08:26] <asac_> yeah what fun this is
[08:27] <asac_> hjmf_:
[08:27] <asac_> 20:10 < hjmf> i think so
[08:27] <asac_> 20:10 < asac> if extension works with our 2.0 package
[08:27] <asac_> 20:10 < asac> then they should file bug at extension author that they fix their compatibility hints in install.rdf
[08:27] <asac_> 20:10 < asac> (e.g. so it gets disabled in 3.0)
[08:27] <asac_> 20:11  * asac brain.TODO.append("apport hook patch to firefox-granparadiso")
[08:27] <asac_> 20:12 < asac> hjmf: so can you retrace the other bugs in the same environment as this one?
[08:48] <hjmf> asac: your connection rules :-P
[08:49] <asac> thanks
[08:49] <asac> i will sell it on ebay i guess :)
[08:50] <hjmf> I can retrace the gusty bugs that can be retraced, but slower than usual
[08:50] <asac> hmmm ... what do you mean by slower?
[08:50] <hjmf> but I'll fix it when I have time
[08:50] <asac> just more CPU cycles? or more manual interaction needed?
[08:50] <hjmf> more manual interaction
[08:50] <hjmf> not a problem
[08:51] <hjmf> will be fixed soon, maybe tomorrow
[08:54] <asac> hjmf: what manual interaction is needed?
[08:55] <amigrave> is there an official firefox build in the ubuntu repositories ?
[08:55] <asac> maybe that info will help us to track down the problem with auto-retracers
[08:55] <asac> amigrave: there are official ubuntu packages ... yes
[08:56] <amigrave> asac: i meant mozilla official build installable via apt
[08:56] <asac> no
[08:56] <hjmf> asac: I'm using apport -g to check all the errors it produces
[08:56] <hjmf> that means running gdb by hand and review what packages are missing
[08:57] <asac> hmmm ... so packages are not properly detected?
[08:57] <hjmf> but just by personal decision, not by an apport problem
[08:57] <asac> he?
[08:57] <asac> so would it work without manual interaction?
[08:57] <asac> (e.g. at least to get basic good results?)
[08:57] <hjmf> I tried and it didn't work right
[08:57] <hjmf> some packages weren't installed
[08:58] <hjmf> dunno why so I went by hand
[08:58] <hjmf> but apport run rightly in the next tries
[08:59] <asac> damn ... so the bug has always been there ... i think this is the issue pitti wanted to look into -> e.g. why aren't proper packages found
[08:59] <hjmf> so there's no problem with apport, maybe I'm insane today
[08:59] <hjmf> hmm
[08:59] <hjmf> not sure
[08:59] <asac> why no problem with apport ... i don't understand that
[08:59] <asac> are you using latest apport?
[08:59] <hjmf> yes
[08:59] <asac> hmmm maybe the old one still works?
[08:59] <hjmf> I have to try
[09:08] <asac> damn i ordered a pizza more than one hour ago ... still no door bell
[09:08] <asac> i am starving
[09:11] <Admiral_Chicago> i'm pretty hungry too
[09:16] <hjmf> I'm going to have dinner right now :D
[09:26] <asac> finally pizza arrived
[09:27] <asac> almost cold of course
[09:34] <Admiral_Chicago> asac: using the latest bughelper?
[09:35] <Admiral_Chicago> bugnumbers -p firefox --lc="d:2007-05-27" > possibleuntouched
[09:35] <Admiral_Chicago> doesn't work for me at version 0.2
[09:35] <Admiral_Chicago> r~183
[09:48] <asac> Admiral_Chicago: hmm ... is that a new feature?
[09:48] <bluekuja> asac: mail sent
[09:48] <bluekuja> :)
[09:49] <bluekuja> I've cced asac@ubuntu.com
[09:49] <bluekuja> I hope its ok
[09:49] <bluekuja> ;)
[09:51] <asac> bluekuja: sure
[09:51] <bluekuja> :)
[09:51] <asac> bluekuja: tomorrow i will figure out what to do next :)
[09:51] <bluekuja> asac: sounds great! :)
[10:19] <bluekuja> asac: I'm leaving
[10:19] <bluekuja> good night
[10:19] <bluekuja> :)
[10:31] <JenFraggle> hello people
[10:33] <Admiral_Chicago> hey there JenFraggle
[10:34] <JenFraggle> how are things here tonight?
[10:35] <Admiral_Chicago> busy with Hug day
[10:35] <JenFraggle> of course, I forgot about that
[10:35] <Admiral_Chicago> asac: were you able to get that bugnumbers query working?
[11:13] <asac> Admiral_Chicago: sorry was doing something else
[11:14] <asac> Admiral_Chicago: do i have to use bzr or what?
[11:14] <asac> how do i use bzr bughelper branch?
[11:14] <asac> i forgot :)
[11:16] <Admiral_Chicago> are you using gutsy?
[11:16] <Admiral_Chicago> you just install bughelper if you are
[11:19] <asac> i have gutsy chroot
[11:19] <asac> i don't want to boot my 'noisy' system with gutsy atm :)
[11:19] <Admiral_Chicago> hmm, okay well then I'll figure it out
[11:19] <asac> wait
[11:19] <asac> i have bzr branch here on disk i see
[11:19] <asac> lets see
[11:19] <Admiral_Chicago> i'm looking to build a list of all the bugs that haven't been touched in 30+ days
[11:20] <asac> hmm i think my branch is outdated
[11:20] <asac> still has ~bugsquad
[11:20] <asac> ... but i am sure that i branched from new location as well
[11:20] <asac> Admiral_Chicago: thats pretty cool
[11:20] <asac> Admiral_Chicago: can we add more conditions to it?
[11:20] <Admiral_Chicago> but i'm not sure, the query is having issues
[11:21] <Admiral_Chicago> yes
[11:21] <Admiral_Chicago> https://wiki.ubuntu.com/BugSquad/Diaries/bdmurray
[11:21] <asac> i mean bughelper conditions ... like <op> ... ?
[11:22] <asac> can we express that in clue files as well?
[11:22] <Admiral_Chicago> date as a condition?
[11:22] <asac> he?
[11:23] <asac> can we say something like date="< $today + 15d" ?
[11:23] <Admiral_Chicago> i thought about that already, the reason I haven't implented it yet is because i'm not sure how to do it.
[11:23] <asac> first: do you know exactly what you want to do?
[11:23] <Admiral_Chicago> that may need to interface with the computers date.
[11:23] <asac> as soon as we know that ... we can definitly figure out a way to do that
[11:23] <Admiral_Chicago> i'd like to look at bugs that have been opened and aren't reproduceable or missing information
[11:24] <asac> yes right
[11:24] <Admiral_Chicago> bug reports that have requests for more information
[11:24] <asac> anyway ... i think there are some meta questions to answer first
[11:24] <asac> i fail to see their definition/destinctions:
[11:24] <Admiral_Chicago> ?
[11:24] <asac> what is a clue file and what is a bugquery ?
[11:24] <asac> is there a difference?
[11:25] <asac> afaik you can do things in bughelper command line tool that you can't do in clue
[11:25] <asac> and vv
[11:25] <asac> why is it that way?
[11:25] <Admiral_Chicago> i don't know
[11:25] <Admiral_Chicago> which is a problem
[11:25] <Admiral_Chicago> i think you could do it in a cue file
[11:25] <Admiral_Chicago> but I'm not sure how
[11:26] <asac> i talked to mkorn and dholbach once short about this ... they ment that its ment to be different
[11:26] <asac> but then they couldn't tell what a cluefile is compared to a bugquery
[11:26] <asac> personally i think a cluefile shoulod be a crawler algorithm :)
[11:27] <asac> e.g. you can refining matches and output comments on matches :)(
[11:27] <asac> s/can refining/ can do refining/
[11:27] <asac> but that is far away from what cluefiles are atm
[11:27] <asac> atm they are just something you cannot really define
[11:28] <asac> they are kind of crawler instruction in that each clue is run on every bug
[11:28] <asac> and the file name used is the only refinement that reduces the crawled set of bugs
[11:28] <asac> hard to describe
[11:29] <asac> you think you understand what i mean?
[11:29] <Admiral_Chicago> reading...
[11:30] <Admiral_Chicago> sorry was in a meeting
[11:30] <asac> ALLBUGS --> (refined -> only bugs with packagename == filename) --> evaluate clue
[11:30] <Admiral_Chicago> yes i know what you mean
[11:31] <asac> so my idea is to make refinement recursive:
[11:31] <asac> ALLBUGS -> [ (refined by clue) -> ] * -> output
[11:31] <asac> stupid implementation would just evaluate clues on on subset previously refined
[11:31] <Admiral_Chicago> i know what you mean
[11:32] <asac> yeah :)
[11:32] <Admiral_Chicago> i'll look at some conditions.
[11:32] <Admiral_Chicago> maybe I can hack it up somehow
[11:33] <asac> smart implementation could refine as much as possible by using query url :)
[11:33] <asac> but first stupid would be enough
[11:36] <asac> Admiral_Chicago: i already looked at it once ... but ran away crying :)
[11:36] <asac> when i looked conditions where no objects, but just strings
[11:36] <Admiral_Chicago> ah okay
[11:37] <asac> which made in infeasible hard to do really expand the feature set
[11:37] <Admiral_Chicago> hmm
[11:37] <Admiral_Chicago> .win 13
[11:37] <asac> but maybe thekorn changed that
[11:37] <Admiral_Chicago> hopefully
[11:37] <Admiral_Chicago> i need a break
[11:37] <asac> maybe look what he did on his branch
[11:37] <asac> i will try to find it :)
[11:37] <Admiral_Chicago> been sitting for two long
[11:37] <Admiral_Chicago> asac: i have a link
[11:37] <Admiral_Chicago> two == four
[11:38] <asac> hehe
[11:38] <Admiral_Chicago> apparently i don't have a link...wth
[11:39] <asac> hmm
[11:40] <asac> does he develop in private?
[11:41] <asac> ok branching latest
[11:44] <Admiral_Chicago> i think he has a branch, maybe its the py-lp-bugs one i saw
[11:45] <Admiral_Chicago> its all on lp
[11:49] <asac> hmmm ... maybe he hasn't begun to work on bughelper?
[11:50] <asac> just on python-lp-bugs?
[11:50] <gnomefreak> this is not looking good at all
[11:51] <gnomefreak> asac: bug 122683 and bug 122389 look like they have same stack both related to glib
[11:51] <ubotu> Launchpad bug 122683 in gnash "gnash crashed with signal 5 in g_logv()" [High,Incomplete]  https://launchpad.net/bugs/122683
[11:51] <ubotu> Launchpad bug 122389 in compiz "gtk-window-decorator crashed with signal 5 in g_logv()" [Medium,Triaged]  https://launchpad.net/bugs/122389
[11:51] <asac> Admiral_Chicago: do you know a good set of fields we can match in clues atm?
[11:51] <asac> tags, states, fulltext (incl. attachments) ... what else?
[11:52] <asac> what the hell is signal 5
[11:52] <asac> why do i see so many signal 5 crashes lately?
[11:52] <asac> SEGV is signal 11 right?
[11:52] <gnomefreak> not sure about that
[11:54] <asac> gnomefreak: that is a bug in x11 / opengl i guess
[11:54] <asac> its BadWindow
[11:54] <gnomefreak> ended up reinstalling to fix the crashes
[11:54] <gnomefreak> gnash shouldnt need opengl
[11:54] <gnomefreak> assuming you mean 3D opengl
[11:55] <asac> opengl has 2d as well
[11:55] <asac> but you are right ... gnash shouldn't use opengl, but it currently does
[11:55] <asac> i have to backport patch to build with agg
[11:55] <gnomefreak> ah ok
[11:55] <asac> hope this brings some heeling
[11:55] <gnomefreak> thats what bluekuja was working on
[11:55] <asac> he worked on libagg rigbht
[11:56] <asac> i have to backport the patch though --- i guess
[11:57] <asac> its really interesting to see the difference of submitting patches to gnome or pushing them to bugzilla
[11:58] <asac> in gnome they get applied immediately
[11:58] <asac> in bugzilla it will take ages if you don't ping them in channel
[11:59] <Admiral_Chicago> asac: i'll have to look at the code. I'm not sure off the top of my head
[12:00] <Admiral_Chicago> afk for a few minues
[12:00] <gnomefreak> i think we have a klash tester for your patch, utube is crashing X with klash i hear
[12:04] <asac> gnomefreak: lots of people crash X :)
[12:04] <asac> nowadays
[12:04] <gnomefreak> hes using klash when it crashes :)
[12:04] <gnomefreak> i was talking to him in #kubuntu-devel
[12:04] <asac> yeah ... opengl can cause any kind of nifty problem with driver you want
[12:04] <asac> and if driver goes down ... X goes down
[12:05] <gnomefreak> yep
[12:05] <asac> which is why we need agg
[12:05] <asac> but if switch to agg now, then there wouldn't be klash at all
[12:05] <gnomefreak> oh that is bad
[12:05] <asac> because 0.8.0 doesn't support agg for kde
[12:06] <gnomefreak> what do we need to wait for? upstream to add support?
[12:06] <asac> if too many people complain about broken klash/konqueror plugin ... i will just disable .-P
[12:06] <asac> less work for me ;)
[12:06] <gnomefreak> lol
[12:06] <asac> gnomefreak: we need someone to backport the changes needed for agg renderer in kde
[12:07] <asac> they have landed on trunk pretty shortly after branch for release was created
[12:07] <asac> so should be not too hard
[12:07] <asac> i will do that if noone else does it ... so we are waiting for me atm
[12:07] <asac> :)
[12:07] <gnomefreak> :)
[12:08] <asac> anyway ... i will talk to gnash devels
[12:08] <gnomefreak> brb need smoke
[12:08] <asac> maybe we even go back to trunk
[12:08] <asac> but for that i need some estimate when they will release 0.8.1
[12:16] <gnomefreak> they just released 0.8.0 didnt they?
[12:16] <asac> yes
[12:16] <asac> but they push much atm
[12:17] <asac> http://codebrowse.launchpad.net/~vcs-imports/gnash/trunk/changes
[12:17] <asac> there are changes
[12:18] <gnomefreak> looks like they push daily
[12:18] <asac> they work a lot
[12:18] <asac> hope they work efficiently as well
[12:18] <asac> they really have a long way to go still
[12:18] <gnomefreak> they are using agg already
[12:18] <gnomefreak> by the looks of it
[12:19] <asac> they have multiple renderers
[12:19] <asac> agg, opengl and something else
[12:19] <asac> fb?
[12:19] <asac> maybe
[12:19] <gnomefreak> ah ok
[12:19] <asac> opengl is not really bad ... its just too hardware dependent
[12:20] <gnomefreak> correct
[12:25] <asac> gnomefreak: when do you want to start merges?
[12:25] <gnomefreak> what merges and as soon as i learn how
[12:26] <asac> gnomefreak: e.g. as a next challenge .)
[12:26] <gnomefreak> if you mean merge new release from debian
[12:26] <asac> yes
[12:26] <gnomefreak> im setting up chroots tonight
[12:26] <asac> for packages on merges.ubuntu.com
[12:26] <gnomefreak> tomorrow sound good?
[12:27] <asac> http://merges.ubuntu.com/universe-manual.html
[12:29] <asac> gnomefreak: actually i am not that familiar with merging procedures (as in how it should be) :) ... so i willl learn something as well
[12:29] <asac> i think:
[12:29] <asac> https://wiki.ubuntu.com/MOTU/Merging
[12:29] <asac> https://wiki.ubuntu.com/MOTU/Packages/Merging
[12:29] <asac> https://wiki.ubuntu.com/MOTU/School/Merging-and-Syncing
[12:29] <asac> should be a good start
[12:29] <asac> :)