=== asac_ [n=asac@debian/developer/asac] has joined #ubuntu-mozillateam [03:44] what is sudo apt-get install gnash too hard? [04:08] asac: we ported gnash for feisty as where people are saying dont use the binaries they dont say it that way :) btw i use it on feisty and no issues === DarkMageZ [n=richard@ppp59-167-30-126.lns1.syd6.internode.on.net] has joined #ubuntu-mozillateam === tonyyarusso [n=anthony@ubuntu/member/tonyyarusso] has joined #ubuntu-mozillateam === Admiral_Chicago [n=House@ubuntu/member/admiral-chicago] has joined #ubuntu-mozillateam [10:28] join #xubuntu-devel [10:29] err... === ..[topic/#ubuntu-mozillateam:Admiral_Chicago] : Home of Ubuntu Mozilla Team - https://wiki.ubuntu.com/MozillaTeam | Bug Triagers please read: https://wiki.ubuntu.com/MozillaTeam/Bugs/ | Firefox trunk package source : https://code.launchpad.net/~asac/firefox/trunk | Mailing List: ubuntu-mozillateam@lists.ubuntu.com | === Admiral_Chicago [n=House@ubuntu/member/admiral-chicago] has left #ubuntu-mozillateam [] === JenFraggle [n=jen@91.84.43.217] has joined #ubuntu-mozillateam [12:34] ok i am going sport now :) ... will be back in 4 hours i guess ;) [12:43] ok [01:27] im sort of here kind of in a way [01:40] sort of, kind of. right... [01:51] its my birthday so im sort of here ;) [01:53] happy birthday!!! [01:54] ty [02:04] are you in usa? i get confused where people are from [02:05] yep [02:06] cool [02:06] i've been looking at the wiki i'm doing but have come to a bit of a standstill. need to speak to asac about it [02:54] @schedule UTC [02:54] Schedule for Etc/UTC: 26 Jun 13:00: Community Council | 26 Jun 15:00: Kernel Team | 27 Jun 12:00: Edubuntu | 27 Jun 20:00: Xubuntu Developers | 28 Jun 15:00: Ubuntu Development Team | 03 Jul 19:00: Technical Board [02:55] asac: and hjmf_ dont forget to show up to CC meeting on 26th :) [03:35] asac: i added your gnash-0.8.0 to the preview arcive wiki https://wiki.ubuntu.com/MozillaTeam/PreviewArchives so people dont have to upgrade ff tb and others if they dont want to :) [03:38] gnomefreak: thats tuesday right? [03:38] yes [03:38] yeah ... will attend [03:38] i think your funkymonkey is borked [03:38] my funkymonkey= [03:38] hehe [03:38] what happens? [03:38] lol [03:39] it doesnt give me download dialog (it did on iceape but failed to create crome dir [03:39] chrome [03:39] gnomefreak: oh ... for iceape i have no idea if it works [03:39] im gonna try to wget it [03:40] anyway ... i have to go out for another 30 min or so ... get some sun and a latte macchiato on the street ;) [03:40] ok have fun :) [03:40] will be here afterwards for full evening [03:40] doing some other stuff, but being in responsive mode :) [03:40] ok cu later === tonyyarusso [n=anthony@ubuntu/member/tonyyarusso] has joined #ubuntu-mozillateam [04:48] here i am :) [04:48] JenFraggle: still there? [04:48] hello [04:48] Bug 120781 becomes more and more mysterious [04:48] Launchpad bug 120781 in firefox "Firefox hangs on websites when using gecko-mediaplayer plug in/gnome-mediaplayer/mplayer" [Undecided,Incomplete] https://launchpad.net/bugs/120781 [04:48] JenFraggle: ola [04:48] JenFraggle: were are you from? [04:49] where [04:49] :) [04:49] uk [04:49] interesting ... because you have a googlemail.com address instead of a gmail.com one [04:49] i thought only germans get those addresses because of trademark infringment [04:49] that is what google gave me :( [04:49] maybe they thought you were german ;) [04:50] not that i matters :) [04:50] just takes longer to type [04:50] JenFraggle: i thin @gmail.com will work too [04:51] JenFraggle: so where did you get stuck in wiki? [04:51] i'm trying that [04:51] the 2 bits you said to put in :o) [04:52] have you read the "states" page? [04:52] yes [04:52] our bug procedures are documented here: https://wiki.ubuntu.com/MozillaTeam/Bugs/Procedures [04:52] ah ok [04:53] i think that page would be a perfect place to fill in a more general introduction [04:53] it is a bit small at present [04:54] exactly ... the states page should be more specific though [04:55] it has the old states on it, doesn't it? [04:55] ok ... just fixed the states page to use the new bug-tracker state Incomplete instead of Needs info [04:55] JenFraggle: just fixed it :) ^^^ [04:55] its still valid [04:56] its not yet clear how we will the Todo and Triaged states ... but since confirmed still exists, there is no need to hurry [04:56] JenFraggle: ok ... so basically our workflow is like this: [04:57] 1. bugs come in as New (previously Unconfirmed) [04:57] incomplete is the one for beginners, is that right? [04:57] JenFraggle: more or less ... yes [04:57] ok [04:57] when bugs come in as "New" someone has to look at it and decide whats next [04:58] in general a bug can be a feature bug, a crash bug ... or a packaging bug [04:58] for now we subsume feature bugs and packaging bugs. [04:58] so basically its just ... either its a crasher ... or something else [04:58] ok [04:59] depending on this there are different activities that need to be done to get a bug started [04:59] for crashers its getting a proper crash report [05:00] ok ... when you see a "New" crash bug you move it to incomplete [05:00] in case there is no crash report attached, the task that needs to get done is a simple wone: [05:00] one: [05:00] mt-needreport [05:01] (so when moving it to Incomplete you set the tag, so people that want to help on needreport bugs can get a good list bugs that they can process) [05:01] ok [05:01] need report task is simple: try to get the crash report the user forgot or didn't manage to attach [05:02] once the crash report is attached it needs a retrace, so we tag it as mt-needretrace [05:02] a retrace allows us to see details of a crash report: [05:02] e.g. where did the crash occur in the program source code and what values were assigned to the variables at the time of the crash [05:03] thus you can use a different name for retrace: "symbolize" [05:03] i see. i haven't done anything like this which so that makes it awkward to write about === hjmf [n=hjmf@81.Red-217-125-221.dynamicIP.rima-tde.net] has joined #ubuntu-mozillateam [05:03] JenFraggle: its not needed to describe in detail ... just like above in your own words would be good [05:04] JenFraggle: think about it like this: [05:04] i just need to have an idea of what happens and at present I don't really know. this is really helpful [05:04] a crash reporter in its initial/raw form is just a huge blob of binary data ... that you cannot see anything about [05:05] retracing aka symbolizing brings makes it readable for human eyes [05:05] ok [05:05] JenFraggle: let me show you an example [05:05] wait a second [05:05] np [05:07] e.g. this is a unsymbolized stacktrace: http://launchpadlibrarian.net/6493913/Stacktrace.txt [05:07] while this is the symbolized one: http://launchpadlibrarian.net/6638744/retraced_Stacktrace.txt [05:07] in the symbolized case you can see exactly in what function it crashed in (e.g. the top most line) [05:07] i wondered why they were really short sometimes, those ones need to be retraced [05:08] yes right [05:08] they are just binary blobs without much sense ... so when you retrace you can see the backtrace ... that is often helpful to figure out the cause [05:08] that is what i was using to do the clue files too [05:08] how to retrace is out of scope for the introduction. [05:09] yes right [05:09] you try to find duplicates by matching the functions in the backtrace [05:09] aka stacktrace :) [05:09] yes [05:10] ok ... lets go further ... if you have specific questions about this (e.g. when writing etc.) you can always ask [05:10] yep sure [05:10] ok ... this is pretty much the end of the "special" treatment of crash reports. === hjmf is stuck with the way apport reports stuff (sorry for the noise) [05:10] nw [05:10] this is the expected output http://paste.ubuntu-nl.org/27023/ [05:10] hjmf: no problem :) [05:11] and this is how apport reports it bug 121996 [05:11] Launchpad bug 121996 in firefox "apport hook test" [Undecided,Invalid] https://launchpad.net/bugs/121996 [05:11] check the ExtensionSummary file [05:11] dunno why [05:11] hjmf: maybe everything that is "multi-line" goes to a attachment? [05:11] yes, that's not the problem [05:11] no it isn't [05:12] whats the problem? [05:12] the problem is that the attachment should have 29 lines as in http://paste.ubuntu-nl.org/27023/ [05:12] and it just have 5 :/ [05:13] I thought it was because the encoding, so I unicode the utf-8 strings [05:13] but no way :/ [05:13] yeah ... my initial idea was that it chokes on some character [05:14] ... age Pack' ( ... <- maybe the apostroph ? [05:14] no, because I tested before and it wasn't there [05:15] ... it is just a string, apport should take it as it is [05:15] hjmf: don't waste too much time in it ... maybe give the apport code a quick glance but if you don't see any obvious bug i would just suggest to write this to a mktemp file and attach that as any file [05:15] anyway ... smells like an apport bug [05:15] apport hooks are probably not that much tested [05:15] we should be one of the lead-users :) [05:15] :) I was thinking of something like that [05:16] maybe it assumes some fixed length? [05:16] have you tried to dump some arbitrary text [05:16] and see if it gets cut? [05:16] I'm gonna test first a dump into a file-like object to see what happens... [05:16] http://pastebin.mozilla.org/105810 [05:16] there is text :) [05:16] hehe [05:17] hjmf: maybe look at code [05:17] e.g. what is done when [05:17] hopefully its well encapsulated and can be seen from code in 1-2 minutes :) [05:17] JenFraggle: where are we? [05:18] ty (and sorry) :) [05:18] hjmf: no problem at all :) [05:18] symbolise [05:18] ah rigth [05:19] ok ... once you have symbolized a crash report you try to find duplicates :) [05:19] in the same time you try to find a testcase ... which is actually the same that you do when you receive a non-crasher bug [05:19] so ... when a testcase is needed you tag it as mt-testcase [05:19] ok [05:20] (note: we are still in incomplete) [05:20] mt-testcase is a more or less simple task as well [05:20] ok [05:20] you try to get a good step by step description from the reporter [05:20] how to reproduce the bug [05:20] if he complains about broken GUI et al you also want screenshots [05:21] basically you are done with mt-needtestcase if there is a description that allows others [05:21] to verify if the bug exists [05:21] makes sense [05:22] so if you find a testcase you can either reproduce with that ... or maybe you cannot reproduce on your own [05:22] fixed bug 122006 (ExtensionSummary.txt) :) [05:22] Launchpad bug 122006 in firefox "apport hook test" [Undecided,New] https://launchpad.net/bugs/122006 [05:22] bye I'm off [05:22] hjmf: great [05:22] cool :D [05:22] bye [05:22] cy [05:22] JenFraggle: in case you cannot reproduce you cannot say: "this is not a bug" ... as it might only appear in some specific setups [05:23] JenFraggle: so you tag it mt-needtester [05:23] JenFraggle: basically mt-needtester exists to verify if the testcase attached is good enough to reproduce by third parties [05:23] ok [05:25] task is like: you try to verify if the testcase works ... and if the bug is not reproducible for everyone you offer to assist to test things for a developer [05:25] ok [05:25] ok ... when you have a testcase that works a bug is not incomplete anymore [05:25] but since you might not be really sure if a bug is complete now ... you tagg it mt-confirm and keep it in incomplete state [05:26] mt-confirm is then a task for skilled people that can review testcase and crash report if its good enough to go on [05:26] if it is, it goes to state confirmed :) [05:26] ok [05:26] otherwise the mt-confirm processor will drop instructions what is still needed and tagg accordingly. [05:26] e.g. if he thinks that the testcase is not good enough he will tagg mt-needtestcase [05:27] ok [05:27] in this way triagers get feedback and will probably learn. [05:27] cool [05:27] ok ... confirmed has again a few sub-states [05:28] in general confirmed exists to find a solution for us [05:28] right [05:28] solution means: either push things upstream (if we cannot deal with them) ... or evaluate a solution [05:29] for pushing things upstream we have two substates: mt-upstream and mt-postupstream. [05:29] mt-upstream exists because bugzilla.mozilla.org has loads of bugs ... and we don't want to post duplicates [05:29] ok [05:29] so we need a few people that try to find if a bug already exists. [05:29] if we are pretty sure that a bug is not yet posted we move to mt-postupstream ... [05:30] that task implies that someone reports an upstream bug and later volunteers to answer questions that mozilla developers might have [05:30] ok [05:31] ok ... if you posted the bug upstream you will tagg it mt-confirm ... so a developer or skilled triager can verify that the bug was submitted properly and that [05:31] its on track ... e.g. the bug was confirmed upstream, which is essential that any mozilla developer will ever look at it === bluekuja [n=andrea@ubuntu/member/bluekuja] has joined #ubuntu-mozillateam [05:32] once the bug is properly posted upstream and on-track the ubuntu bug moves to state "in progress" [05:32] as there is not much more to do for us [05:32] we delegated the bug upstream [05:32] ok [05:32] ok ... for bugs that are important enough that we fix them on our own ... or if they are ubuntu specific bugs (like packaging problems) [05:33] we tag things as mt-eval instead of mt-upstream [05:33] this means that people should evaluate where the problem stems from and how we can fix things [05:33] ok [05:33] those bugs are probably the ones that need most knowledge about packaging and even C/C++ coding in some cases === JenFraggle shudders [05:34] and are probably suitable for MOTUs or someone else interested in that [05:34] :) === JenFraggle relaxes [05:34] there are cases where we want to help upstream (if they are important) ... those are mt-eval as well. [05:35] ok ... as always when evaluation is done and solution is outlined in the bug you can tag mt-confirm [05:35] so developer can again verify that it really is feasible and can be worked on [05:35] ok [05:35] for now the developer moves those bugs to In progress as well ... but i think we will use triaged as well [05:35] not as well, but instead of it [05:36] so in progress really means ... its in progress (like in someone is working on it) [05:36] sure [05:37] ok .. i think the rest is easy to understand ... when bugs that are in progress get fixed .. the ideally go to "Fix Committed" as soon as there is a patch available or the fix was really committed to some repository [05:37] once we release a package with that fix it goes to "Fix Released" :) [05:37] then we are done [05:37] cool [05:37] and have processed the bug from New to Fix Released [05:38] most bugs that go to cofirmed should get fix released at some point (in an idealistic world) [05:38] keep the punters happy and all that [05:38] but hopefully most bugs won't go to confirmed, but are rejected in state incomplete as "Invalid" [05:39] not hopefully ... but if you don't get a good testcase out of a bug you often just cannot fix it. [05:39] so crashers without duplicates and no testcase get rejected after some time of inactivity (i think its 2 month now) [05:39] ok [05:39] if a bug doesn't find any valid tester it gets invalid as well at some point [05:40] same of course for testcase [05:40] makes sense [05:40] however if the process is perfect there would be nearly zero Confirmed -> Invalid transitions ;) [05:40] but in reality that will happen as well i guess [05:41] ok i think thats enough [05:41] hopefully ubuntulog recorded this seession :) [05:41] so you can reread ;) [05:41] lets see [05:41] i was going to save transcript. i don't know about ubuntulog [05:42] yeah please save as well :) [05:42] just in case the ubuntulog was broken [05:42] hmmm its here: http://people.ubuntu.com/~fabbione/irclogs/ubuntu-mozillateam-current.html [05:42] but doesn't appear to be 'live' ... or even broken [05:43] i have saved a transcript [05:43] JenFraggle: maybe you can post this transcript to wiki ? [05:44] somewhere linked from the bug procedure page :) [05:44] as is or edited? [05:44] dunno ...maybe cut the hjmf discussion [05:44] the rest is good as a transscript [05:45] ok [05:45] hope it was a bit helpful :) [05:45] very helpful, thanks [05:45] i think you need to chew on this ... especially since i ran through the confirmed state :) [05:46] but i tried my best :) [05:46] i'll work on this and let you know when i'm ready to find out where to find good beginner ones which was the other suggestion [05:46] yeah cool! [05:47] it's good for me too as i'm learning by doing the wiki [05:47] anyone on gutsy here? ... does the "report bug ..." menu entry still exist in firefox gutsy? [05:47] building up to being brave enough to have a go at a bug myself one day [05:47] JenFraggle: edit right away [05:48] JenFraggle: yes ... you can definitly help on Incomplete bugs ... maybe i will find the time to gather some good bugs as a reference to see how easy things are ;) [05:48] thanks [05:48] JenFraggle: otherwise if you subscribe to mozilla-bugs [05:48] and read some of the bugs ... then you should be able to see how things work :) [05:48] asac: i think i have already [05:49] ah cool [05:49] don't be shy ... we read most reports and if you really do things wrong, we will fix things and let you know :) [05:49] which is not bad at all [05:49] ;) [05:49] its often easier to learn by doing than just by watching :) [05:50] well i'm going to log off now and do some work on it, thanks for your help [05:50] JenFraggle: yeah ... thanks 2 [05:50] cu === asac doing something else ... will be available though :) === Admiral_Chicago [n=House@ubuntu/member/admiral-chicago] has joined #ubuntu-mozillateam === Admiral_Chicago [n=House@ubuntu/member/admiral-chicago] has left #ubuntu-mozillateam [] [06:18] heya asac [06:18] :) [06:18] it was --enable-renderer=Agg and? === Admiral_Chicago [n=FreddyM@ubuntu/member/admiral-chicago] has joined #ubuntu-mozillateam [06:36] yeah [06:36] bluekuja: --disable-klash :) [06:36] but s/Agg/agg/ ;) [06:36] thanks [06:36] I'm quite angry now [06:36] why? [06:37] for a guy that commented my work [06:37] he? [06:37] which work? [06:37] I did an error in versioning a package [06:37] on a debdiff [06:37] url? [06:37] and he said "your broken debdiffs (I don't think that's the first time)" [06:37] he dont know me [06:37] and my work [06:38] and he say stuff like that [06:38] OMG [06:38] hmm ... a troll? [06:38] a MOTU [06:38] url? [06:41] https://bugs.launchpad.net/bugs/121593 [06:41] Launchpad bug 121593 in gmsh "Merge gmsh (2.0.7-1.1) from debian unstable" [Wishlist,Incomplete] [06:41] asac: that's it [06:42] ok ... i don't see much offending in there [06:42] adri2000 ? [06:42] pm ;) [06:42] yea [06:43] bluekuja: he is french ... so not a native speaker [06:43] try to assume good faith [06:43] I'm italian [06:43] not native too [06:44] yeah ... doesn't matter ;) ... some are better in english ... some are worse [06:44] french tend be at the bottom of the foodchain ;) when it comes to english ;) [06:45] I know [06:45] but it's what he wants to mean [06:45] hehe ... did he tell you what other parts are not-good of the debdiff? [06:45] nope [06:45] just versioning [06:45] (my error) [06:46] bluekuja: which debdiff got uploaded? [06:47] i think adri's comment: "And it seems that the sponsor who uploaded the first debdiff failed to see that it was a bad debdiff." [06:47] points out that the sponsor took the wrong one :) [06:47] e.g. the one with cruft [06:47] so nothing against you, but the sponsor that is [06:47] he uploaded second one [06:47] then I made [06:47] and bug-fix [06:47] and it got applied [06:48] on debian [06:48] instead of ubuntu previous version [06:48] (bug-fix not a merge) [06:48] ah ok [06:49] bluekuja: just go on :) [06:49] dunno if you pinged im through pm first [06:49] in case, just don't do it in future [06:49] I'm currently talking with him [06:50] I dont like what he said [06:50] hmm [06:50] be careful [06:50] you might esacalate this whole thing by bugging him [06:50] do it in public [06:50] I just want to clarify what he said me [06:50] then things will be better thought out [06:50] he said that [06:51] "when a motu told me "you did that wrong" I said "ok", fixed it, etc." [06:51] and btw it's what I do [06:51] but I've never heard of a MOTU [06:51] that comments out my work [06:51] like he did [06:51] yeah ... just remember: "when you feel angry", stop communicating about that issue until you found rest :) [06:51] respect is something everyone should have [06:52] ok [06:52] i really have no idea what exactly was said :) ... just do what you want ;) [06:53] just be nice :) [06:53] hard to be nice [06:53] when I'm angry like now [06:56] asac: this things make me feel really sad [06:56] *these [07:03] asac; I'm building gnash with those two configure variables, then I check if it builds against libagg [07:03] and then we're done [07:07] bluekuja: get over it ... its not worth to waste any emotional affection on this .... most people are nice [07:07] however there always will be conflicts, smart-ass et al [07:07] lol [07:07] bluekuja: actually I would like to have klash as well [07:07] but atm it doesn't build with agg [07:07] e.g. configure fails [07:07] ah yea [07:08] so ... to get klash going with agg we need to backport something from cvs HEAD [07:08] once gnash builds well with agg we can do ... try that. [07:08] anyway ... for agg it should be enough to see that gnash without klash works [07:08] ... so we can upload new agg version : [07:08] ) [07:08] :) [07:08] now building [07:29] asac: what do you think about https://bugs.launchpad.net/ubuntu/+source/firefox-themes-ubuntu/+bug/107165? [07:29] Launchpad bug 107165 in firefox-themes-ubuntu "patch to add menu icons" [Undecided,Confirmed] [07:33] bluekuja: src/custom/browser.css.diff looks broken [07:33] looks like its a diff of a diff [07:33] yeah [07:33] though the original diff wasn't even unified [07:33] well I'll leave it where it is then [07:33] maybe ask author for clarification [07:34] ok [07:40] asac; I'm getting a E: Couldn't find package swfmill [07:40] in unstable [07:41] build-machine is updated [07:41] I can see it on debian PTS [07:43] checking something [07:45] ok fixed [07:45] ;) === JenFraggle [n=jen@91.84.43.217] has joined #ubuntu-mozillateam [07:51] bluekuja: ah you work on debian? [07:51] i was thinking you are doing this on ubuntu ;) [07:52] asac: yeah, using debian build-machine [07:52] :) [07:52] anyway swfmill should be in debian [07:52] yup [07:52] while its not in ubuntu afaik [07:52] yeah [07:52] should not be needed for gnash [07:52] why do you get it? [07:52] bluekuja: please don't use debian package [07:52] but ubuntu source [07:52] debian is stuck in NEW [07:52] so in debian you get old package [07:53] version should be 0.8.0something [07:53] yup [07:54] and in that package there is no swfmill build-dep :) [07:54] or build from bzr [07:54] its in my code [07:54] page on launchpad [07:55] asac: should i use ubuntu's debian dir for gnash? [07:55] not debian one then [07:55] yes forget about debian [07:55] :) [07:55] use ubuntu's or my bzr branch [07:55] ok [07:55] and the ubuntu orig [07:56] asac: branch name? [07:57] for gnash [07:57] https://code.launchpad.net/gnash/ [07:57] http://bazaar.launchpad.net/~ubuntu-core-dev/gnash/ubuntu [08:23] http://codebrowse.launchpad.net/~vcs-imports/gnash/trunk/revision/vcs-imports%40canonical.com-20070609194204-el9jsq041wcjon2l?start_revid=vcs-imports%40canonical.com-20070624054940-2eipisj3y0clxv5d [08:23] thats somehow the diff we need on branch :) [08:23] to get kde build with agg [08:24] http://people.ubuntu.com/~asac/klash_agg_trunk.diff [08:24] :) [08:25] if we are happy it just applies ... but more likely that need to be merged somehow [08:25] but who knows :) [08:25] bluekuja: ^^^ === gnomefreak [n=gnomefre@ubuntu/member/gnomefreak] has joined #ubuntu-mozillateam [10:38] asac: back [10:38] :) [10:39] ./autogen.sh [10:39] make: ./autogen.sh: Command not found [10:39] building gnash [10:40] (new) === gnomefreak wonders why the ,.autogen.sh [11:27] i mean /. === gnomefreak gone agian