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