[00:00] <asac> Volans: i don't test if it works, but it builds properly at least
[00:00] <fta> mozilla bug 426565
[00:00] <ubotu> Mozilla bug 426565 in Plug-ins "Firefox 3 crashes with Java applets" [Blocker,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=426565
[00:00] <Volans> good! I'm checking the other extension for the control file
[00:00] <asac> Volans: take a look at a few
[00:00] <asac> not that you accidentially look at one of the few bad examples
[00:00] <asac> ?
[00:00] <asac> ;)
[00:01] <Volans> ok ;)
[00:02] <asac> fta: i don't think thats related to the crashes you see
[00:02] <fta> http://ubuntuforums.org/showthread.php?t=746777
[00:03] <fta> i don't see java crashes, i barely use java
[00:03] <fta> i see frequent flash crashes
[00:04] <asac> fta: since you see issue, can you see if you can reproduce with instructinos on bug 212883
[00:04] <ubotu> Launchpad bug 212883 in firefox-3.0 "firefox crashed with SIGSEGV in __kernel_vsyscall() - Flashplugin nonfree" [Undecided,New] https://launchpad.net/bugs/212883
[00:04] <asac> is that guy seeing the same crash?
[00:07] <asac> fta: does that forum thing crash X for you too?
[00:08] <fta> i haven't tried.. I have zillions of windows opened on my desktop
[00:08] <fta> ;P
[00:11] <fta> http://paste.ubuntu.com/6541/
[00:13] <fta> asac, i think we should keep our patch, it's too late for hardy, what do you think?
[00:13] <asac> yeah i think we should stay buggy ;)
[00:14] <asac> i doubt that its gone
[00:14] <asac> which version do we have
[00:15] <fta> 1.4.0.90 or something like that
[00:16] <asac> yeah
[00:16] <asac> i think its obvious
[00:16] <asac> :)
[00:17] <asac> they align with fedora release?
[00:20] <asac> fta: yay, toolkit@mozilla.org works
[00:20] <asac> now i am happy ;)
[00:20] <fta> what for ?
[00:20] <fta> bug 211791
[00:21] <ubotu> Launchpad bug 211791 in cairo "Please sponsor cairo 1.5.16-0ubuntu1" [Undecided,New] https://launchpad.net/bugs/211791
[00:21] <asac> http://paste.ubuntu.com/6543/
[00:22] <fta> oh
[00:22] <asac> fta: you attached the wrong debdiff ;)
[00:22] <fta> when will the langpacks be released ?
[00:22] <asac> 23 apr :)
[00:22] <fta> no, it's my old bug, i'm updating it
[00:23] <asac> k
[00:23] <fta> 23 apr ??
[00:23] <asac> one day before release ;)
[00:23] <asac> just kidding
[00:24] <asac> asap is the only answer i have right now ;)
[00:24] <Volans> asac: I don't know if here is the right place, I have noticed that if the it_IT locale is set on hardy, FF3beta5 has the english layout and the Lithuanian (lt) welcome page at start. I don't know where is checked the current locale in the installation process
[00:24] <asac> Volans: thats expected
[00:24] <asac> its our contribution to the worlds level on english education ;)
[00:25] <asac> Volans: no, like what we just talked about  ... langpacks are baking longer than expected ;)
[00:25] <Volans> for english no problem... but Lithuanian welcome page??? I think is a mistyping between "lt" and "it", the welcome pages are all correctly created
[00:26] <asac> Volans: yes thats an ubufox bug iirc
[00:26] <asac> its fix committe
[00:26] <asac> d
[00:26] <asac> next upload will fix that bug
[00:26] <Volans> ok, I have searched in the bugs but non found it, my fault
[00:27] <asac> bug 212446
[00:27] <ubotu> Launchpad bug 212446 in ubufox "[Hardy] Ubufox locale for IT-it set to lt (Lithuanian)" [Medium,Triaged] https://launchpad.net/bugs/212446
[00:27] <asac> well, fixed in upstream branch for now
[00:28] <asac> but given that next release will be 0.5 final, thats fix committed
[00:28] <asac> bug 212446
[00:29] <asac> fta: your extension script ... maybe it should be included in a mozilla-extensiontools branch/package ;)
[00:29] <asac> hehe
[00:30] <asac> or just mozilla-devscripts;)
[00:30] <fta> why not.
[00:30] <asac> but actually i woul dlikel to keep devscripts something oyu have in build-dependencies
[00:30] <asac> so maybe use mozilla-devtools ;)
[00:30] <asac> for binary helpers of all kind
[00:30] <asac> binary aka executable
[00:32] <asac> mozillateam-tools ;)
[00:32] <fta> but this is still a script useful only to us
[00:32] <asac> yes
[00:32] <asac> so using a team name ... for now just a branch
[00:33] <asac> but i want to throw my LP bugs python scripts in there as well
[00:33] <asac> which might be useful for others
[01:23] <fta> mozilla bug 419715
[01:23] <ubotu> Mozilla bug 419715 in GFX: Thebes "Upgrade cairo to 1.6 final or as-close-as-possible" [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=419715
[01:24] <fta> but backed out just after...
[01:39] <asac> ok night
[05:54] <[reed]> asac: still need me?
=== asac_ is now known as asac
=== rzr is now known as rZr
[08:54] <asac> [reed]: yeah ;)
[08:54] <[reed]> oh?
[08:54] <asac> [reed]: but let me get some coffee first ;)
[08:55] <asac> ~5 min
[09:02] <asac> mozilla bug 386844
[09:02] <ubotu> Mozilla bug 386844 in Plug-ins "Crash when running Java Applets [@ XSync - JavaPluginInstance5::SetWindow]" [Critical,Verified: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=386844
[09:03] <asac> bug 207907
[09:03] <ubotu> Launchpad bug 207907 in firefox-3.0 "Firefox 3 Beta 4 crashed while displaying a flash-popup" [Medium,Confirmed] https://launchpad.net/bugs/207907
[09:04] <asac> [reed]: look at the comment in launchpad bug please
[09:05] <[reed]> so, file a new a bug, mark it as a regression, make it block that bug
[09:05] <asac> so why was the window setting code moved after CreateXEmbedWindow is called in the moz bug above
[09:05] <[reed]> and request blocking
[09:05] <[reed]> and cc karlt
[09:05] <asac> hey ;)
[09:05] <[reed]> if you want to talk to karlt first, ping him :p
[09:06] <asac> yeah
[09:06] <[reed]> just because I land a patch doesn't mean I have anything to do with it :)
[09:06] <asac> hehe
[09:07] <fta> mozilla bug 427385
[09:07] <ubotu> Mozilla bug 427385 in GFX: Thebes "april 6th ff3 trunk crash when opening this huge PNG [XError: 'BadAlloc (insufficient resources for operation)']" [Critical,Assigned] http://bugzilla.mozilla.org/show_bug.cgi?id=427385
[09:08] <fta> hi
[09:11] <[reed]> hi, fta
[09:17] <asac> fta: do you see any messages on console when flash crashes for you?
[09:18] <fta> none that i remember
[09:18] <fta> and gdb stack is often unusable
[09:19] <fta> it even often crashes gdb
[09:21] <asac> fta: can you break at http://lxr.mozilla.org/seamonkey/source/modules/plugin/base/src/nsPluginNativeWindowGtk2.cpp#176
[09:21] <asac> ?
[09:21] <asac> and see whats parent_win at that point?
[09:22] <asac> or add some printf
[09:27] <fta> i will but not now, i'm working
[09:28] <asac> yeah
[10:07] <asac> fta: debian bug 449448 closed :/
[10:07] <ubotu> Debian bug 449448 in xulrunner "Please package xulrunner 1.9 in the upstream way" [Wishlist,Fixed] http://bugs.debian.org/449448
[10:11] <asac> apparently mike decided to not use a patch system
[10:11] <asac> great
[10:11] <asac> have fun
[11:45] <asac> carlos: did the b5 upload go well?
[11:45] <carlos> asac: no, it was not extracted from the package
[11:45] <carlos> did pitti installed the updated script on buildds?
[11:45] <asac> ydes
[11:46] <carlos> hmm
[11:46] <asac> carlos: pkgstriptranslations: preparing translation tarball xulrunner-1.9_1.9~b5+nobinonly-0ubuntu1_i386_translations.tar.gz...done (1 files)
[11:46] <asac> http://launchpadlibrarian.net/13134827/buildlog_ubuntu-hardy-i386.xulrunner-1.9_1.9~b5%2Bnobinonly-0ubuntu1_FULLYBUILT.txt.gz
[11:47] <carlos> I'm working on some open bugs for firefox, I will review the process in our side, maybe we are assuming .po or .pot files...
[11:55] <carlos> asac: btw, did you manage to get back an .xpi file from the export I gave to you?
[11:55] <asac> carlos: i am currently working on the process to prodduce the packages we want to ship for hardy
[11:55] <carlos> from the language pack, right?
[11:56] <asac> carlos: yes
[11:56] <asac> a script that produces .deb package structures from the complete export
[11:56] <asac> ... doing that i will see if it something broke
[11:57] <asac> but i could get a working .xpi from the previous exports you gave me
[11:57] <carlos> cool!
[11:57] <asac> so i hope that it didn't change anything (except improvements)
[11:57] <carlos> :-)
[11:57] <asac> i had some issue with accesskeys ... but i have to look closer whats going on
[11:58] <asac> i think it were just untranslated ones
[11:58] <carlos> if you have something I can debug, is the right time
[11:58] <carlos> I'm going to request a patch cherry pick into production for some remaining problems with xpi support
[11:58] <asac> carlos: ok ... ill give you feedback today
[11:59] <carlos> so is a good time to get that fixed now or will need to wait until the end of the month (only minor fixes, please)
[11:59] <carlos> asac: cool
[11:59] <asac> what are the problems you are seeing?
[12:05] <asac> carlos: the really bad thing is that i couldn't go through german translations still
[12:05] <asac> nobody replied
[12:05] <asac> so i am not a translator
[12:05] <asac> carlos: does the cherry pick include to use the suggestion if there is only one suggestion?
[12:05] <asac> that should eliminate a lot of those not auto translated keys
[12:07] <carlos> no, that's nothing I can do in a reliable way because that's only true today, but when translators start doing suggestions, I cannot control that...
[12:08] <asac> carlos: right ... but it would give us a better start
[12:09] <asac> now we have 500 untranslated strings per language
[12:09] <carlos> asac: the problem is that Launchpad production is nothing that could have some code running and then easily disable it. I don't have direct access to the server and I need to follow some procedures
[12:10] <asac> carlos: but if ... after import of translation ... there is no translation, but only one translation that was just imported, we could auto approve that ;)
[12:10] <carlos> which is good for a good QA, but makes impossible those fast and easy temp hacks
[12:10] <asac> s/one translation/one suggestion/
[12:10] <carlos> asac: that's not completely true, even if that's what it shows in the UI
[12:10] <asac> ?
[12:10] <carlos> the problem is that we are getting a context string
[12:10] <carlos> that shouldn't be there
[12:11] <carlos> so the messages are different in our database
[12:11] <carlos> however, the suggestion system ignores that context string
[12:11] <carlos> and that's why it appears there
[12:11] <asac> k
[12:11] <carlos> but we cannot ignore the context string to approve automatically translations
[12:12] <carlos> or that would make useless the context feature. The proper fix is to stop adding those context string... but that' snot trivial to fix as a cherrypick, it needs to wait until the next rollout (end of the month)
[12:12] <asac> ok ... lets hope that translators are more responsive than the leads of the german team
[14:10] <asac> carlos: we already fixed that accesskey-accept was empty right?
[14:11] <carlos> well, it should be fixed. Did you get it again in the tarball I gave you last week?
[14:11] <carlos> if it's still there, it may be something else
[14:12] <asac> carlos: no ... i ended up approvin suggestions and found that its still on lp
[14:12] <carlos> I see
[14:13] <carlos> ok, I will take a look to it too
[14:14] <asac> carlos: i still see a bunch of ... uk.po:msgid "accesskey-accept"
[14:14] <asac> in the tarball you gave me
[14:14] <carlos> if there is at least one, it's normal that we get more of one....
[14:14] <asac> sure
[14:14] <asac> s/bunch//
[14:14] <asac> :)
[14:15] <asac> appears they are still processed like accesskeys were processed in the past
[14:27] <asac> carlos: intl.charset.detector is a not accesskey that has the same issue
[14:27] <carlos> as I said, the fact that you have the key maybe just that, for some reason, we are missing the translation from en-US
[14:27] <carlos> so my bet is that is not really related with accesskeys
[14:28] <asac> ok
[14:28] <asac> carlos: ok ... thought it was a left over from accesskey special treatment in the past
[14:29] <asac> ok, i assume you don't need more examples/infos about untranslated english texts then :)
[14:31] <carlos> I hope there is only one single cause for that problem ;-)
[15:09] <asac> carlos: there are also others that have a valid english text, but the right translation doesn't show up as suggestion:
[15:09] <asac>  Located in en-US.xpi/en-US.jar!/locale/browser/pageReport.dtd(caption.label)
[15:09] <asac> English:   	 Copy text   	
[15:10] <asac> Blocked Pop-ups
[15:10] <asac> but those appear to be really rare
[15:11] <asac> hmm at least there is a line. the next that has this problem has as key "caption.label" ... as well
[15:12] <asac> carlos: do you wnat a few examples for such keys?
[16:20] <carlos> asac: if you you think they follow the same failure pattern, a single example is enough
[16:21] <asac> carlos: i cannot tell. most are like accesskey: "the key is in english text"
[16:21] <asac> carlos: but some have an english text that is valid, but no suggestion at all
[16:21] <asac> and others have two suggestions that don't fit
[16:22] <asac> either only two suggestions are displayed (?) or the german translation was not parsed
[16:23] <carlos> if you talk about lack of translations, but not that the English string is the ID
[16:23] <carlos> forget about it
[16:23] <carlos> that's all the same problem
[16:23] <carlos> and it will make no sense when you look at the data, the problem depends on how the translator prepared the original .xpi file
[16:23] <asac> ok ... so: 1) lack of translation -> triaged
[16:23] <asac> 2) keys as english text -> Not yet known?
[16:24] <carlos> that's why I told you we cannot do the autoapproval as you suggested
[16:24] <carlos> asac: right
[16:24] <asac> carlos: but lack of suggestions falls into 1) ?
[16:29] <carlos> asac: I think so, yes
[17:53] <Volans> asac: in LP to create the brach for my extension, I have to register a branch here? https://code.edge.launchpad.net/firefox-extensions/+branches
[17:53] <Volans> s/brach/branch
[17:53] <asac> Volans: no you just need to push
[17:53] <asac> Volans: look at the push instructions documented on other branches
[17:54] <asac> well .. bzr+ssh://bazaar.launchpad.net/~$USERID/firefox-extensions/YOUREXTENSION.ubuntu
[17:54] <asac> well .. bzr+ssh://bazaar.launchpad.net/~$USERID/firefox-extensions/YOUREXTENSION.upstream
[17:54] <asac> thats where you need to push
[17:54] <asac> USERID is your launchpad accountname
=== rZr is now known as Rz
=== Rz is now known as RzR
[18:05] <shirish> asac: fta: either of u guys online
[18:06] <shirish> asac: any idea when we will have firebug?
[18:10] <asac> shirish: isn't it avail?
[18:11] <shirish> asac: nope, it isn't, I just did a search
[18:11] <shirish> aptitude search firebug
[18:11] <shirish> no results
[18:12] <asac> shirish: its still in binary NEW
[18:12] <asac> be patient for another day or so
[18:12] <shirish> ok, will do :(
[18:13] <shirish> try to catch an archive admin (perhaps hobbsee and see if it can put up)
[18:15] <asac> shirish: yes, if hobsee is around that would be a good thing
[18:16] <cwong1> asac: morning
[18:16] <asac> cwong1: hi
[18:16] <cwong1> asac: how can I tell the package that I uploaded last Friday to ppa built ok?
[18:17] <asac> cwong1: did you get an "Accept" mail?
[18:17] <cwong1> yes
[18:17] <asac> cwong1: if so, not getting a "failed to build" is a good indicator that it worked
[18:17] <cwong1> asac: ok
[18:17] <asac> cwong1: otherwise you can look at the +archive webpage
[18:17] <asac> and see the .debs there
[18:17] <cwong1> asac: tx
[18:18] <asac> cwong1: you can get to that page from the teams sstartpage on launchpad
[18:18] <asac> cwong1: https://edge.launchpad.net/~ubuntu-mobile
[18:18] <asac> cwong1: https://edge.launchpad.net/~ubuntu-mobile/+archive
[18:19] <cwong1> asac: got it
[18:19] <asac> looks like there are debs available
[18:19] <asac> are those xul builds?
[18:19] <asac> look pretty big to me
[18:19] <asac> (for system-xul)
[18:20] <cwong1> I modified the debian/rule file to build with system-xul.  so it should be unless I screwed up somehow
[18:20] <cwong1> I will look into it.
[18:20] <asac> looks lke there are at least parts of xul
[18:21] <asac> $ ls /usr/lib/firefox-3.0b3/chrome/*.manifest
[18:21] <asac> /usr/lib/firefox-3.0b3/chrome/browser.manifest  /usr/lib/firefox-3.0b3/chrome/en-US.manifest
[18:21] <asac> /usr/lib/firefox-3.0b3/chrome/classic.manifest  /usr/lib/firefox-3.0b3/chrome/reporter.manifest
[18:21] <asac> thats what is in firefox 3.0 system-xul build in chrome
[18:22] <fta> yop
[18:22] <asac> hmm definitly a full build judging from the build times
[18:23] <asac> cwong1: did you push that to git yet?
[18:24] <asac> hmm .... git has --with-libxul-sdk=$(ls -d /usr/lib/xulrunner-devel-1.9*)
[18:24] <cwong1> asac: I pushed it to the hardy branch last friday and did a release.
[18:24] <Volans> asac: another quite stupid question, the extension is compatible also with Flock, I have to do something special for that? The deb actually install only in FF obviously
[18:24] <asac> fta: do you see anything that might break system-xul in tree: http://www.moblin.org/repos/?p=projects/mobile-browser.git;a=tree;h=hardy;hb=hardy
[18:24] <asac> well go to hardy branch (bottom of page)
[18:24] <cwong1> asac: does the build system use my debian directory for the build?
[18:25] <asac> cwong1: it will whatever you uploaded
[18:26] <asac> use
[18:27] <asac> cwong1: i see the fault :)
[18:27] <asac> cwong1: look at the build log: http://launchpadlibrarian.net/13124817/buildlog_ubuntu-hardy-i386.midbrowser_0.3.0b5a-1_FULLYBUILT.txt.gz
[18:27] <asac> and search for --with-libxul-sdk
[18:27] <asac> what do you see ;)
[18:28] <cwong1> asac: blank
[18:28] <asac> cwong1: you should really really consider to use the debian/ dir of our firefox tree
[18:29] <asac> especially because we are late in release ... there are other tweaks in like overwriting LDFLAGS
[18:29] <asac> because you might end up in crashes otherwise
[18:29] <asac> at least unset LDFLAGS in rules
[18:29] <asac> cwong1: why is it blank ;)?
[18:30] <asac> cwong1: hint, build-dependencies (without looking)
[18:30] <cwong1> asac: I think it didn't like it becuase it was in a variable assingment.. bad idea
[18:31] <asac> cwong1: you lack xulrunner-1.9-dev in control (thats my guess). so it falls back to in-source xul
[18:32] <asac> cwong1: pbuilder is a good tool to test local builds in a buildd like environment
[18:33] <cwong1> asac: I am sure I have xulrunner-1.9-dev in my control file
[18:33] <asac> hmm ... $$ ?
[18:33] <asac> cwong1: we have
[18:33] <asac> DEBIAN_XUL_DEV  := $(wildcard /usr/lib/xulrunner-devel-1.9*)
[18:33] <asac> and --with-libxul-sdk=$(DEBIAN_XUL_DEV)
[18:34] <cwong1> asac: I am going to set up a local build system to do the test build before I upload a fix.
[18:34] <cwong1> asac: I will fix it do  a test build before my next upload today...:(
[18:34] <Volans> asac: I have to add and commit only the pure code or also the ./debian/ folder and/or other files? (I have seen various preactice in other extensions)
[18:35] <asac> cwong1: if that doesn't consume much time ... good. otherwise as long as its not like 10 tries uploading to ppa should be fine ;)
[18:35] <asac> or pbuilder
[18:35] <asac> Volans: take a look at the packagin page in wiki
[18:35] <asac> Volans:  https://wiki.ubuntu.com/MozillaTeam/Firefox3Extensions/Packaging
[18:36] <asac> in short: you should create an .upstream branch with only your extension files in ... and a .ubuntu branch based on that ... with the debian/ dir
[18:38] <Volans> ok, thanks, I'm checking in the wiki
[19:14] <fta> asac, https://code.edge.launchpad.net/~mozillateam/mozilla-devscripts/mozilla-devtools
[19:16] <asac> fta: cool ;)
[19:16] <asac> a glorious start
[19:22] <fta> :)
[19:31] <Jazzva> asac, have you took a look at foxyproxy? (Maybe you missed it yesterday, I mentioned it was done while you were away)
[19:32] <fta> Jazzva, http://paste.ubuntu.com/6571/
[19:33] <Jazzva> Great work, fta :). That will help a lot with new upstream versions checking :)...
[19:33] <Jazzva> BTW, I forgot to ask you yesterday... Mind if I take a look at the source? I would like to learn something from it...
[19:33] <fta> my code is now a new branch: https://code.edge.launchpad.net/~mozillateam/mozilla-devscripts/mozilla-devtools
[19:34] <fta> +in
[19:34] <Jazzva> aaah, great... Will branch it and take a look :).
[19:36] <Jazzva> btw, is it possible to push extensions in backports, once new upstream versions come out?
[19:36] <Jazzva> *to backports...
[19:37] <fta> for gutsy ?
[19:37] <Jazzva> no, I meant for hardy...
[19:38] <Jazzva> Once hardy comes out, we start packaging new upstream versions for interpid (not too catchy :)). Is it possible to push them to hardy too?
[19:39] <fta> i don't really know the backports rules
[19:39] <Jazzva> Hmm... maybe wiki knows something... or ubotu
[19:39] <Jazzva> !backports
[19:39] <ubotu> If new updated Ubuntu packages are built for an application, then they may go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging
[19:39] <Jazzva> ahhh :)
[19:39] <fta> :)
[19:44] <fta> so, did you learn something ?
[19:44] <Jazzva> It might...
[19:44] <fta> it's not rocket science
[19:45] <fta> kind of hackish
[19:45] <Jazzva> Candidates for version updates are primarily desktop applications, such as your web browser, word processor, IRC client, or IM client.
[19:45] <Jazzva> Extensions are browser related ... :)
[19:46] <fta> I meant, from my script ;)
[19:46] <Jazzva> Oh... haven't seen it yet...
[19:46] <Jazzva> :ashamed:
[19:47] <Jazzva> branching...
[19:48] <fta> there's just 1 file
[19:49] <Jazzva> and it's still not done, for some reason unknown to me :/
[19:49] <Jazzva> looking in the browser...
[19:50] <Jazzva> typo... "porject" :)
[19:51] <fta> ?
[19:51] <Jazzva> PORJECT=firefox-extensions
[19:51] <fta> oh
[19:51] <Jazzva> nothing big :)
[19:53] <fta> strange that it worked...
[19:53] <Jazzva> You used it in second line too ;)
[19:54] <fta> and later
[19:54] <Jazzva> but then, there are lines which say "project"
[19:54] <Jazzva> interesting :)
[19:55] <fta> fixed
[19:55] <jetsaredim_> anyone here an ebay user?  I seem to get firefox to crash consistently when I try to login to ebay
[19:55] <Jazzva> Funny ... Xchat is still crashing for me, when I right click on a nickname... I might report a bug
[19:58] <Jazzva> Script is cool :)...
[19:58] <Jazzva> And there's a lot for me to learn :)
[20:22] <fta> http://glandium.org/blog/?p=191
[20:50] <asac> Jazzva: usully backports are constrained by the man power available to do them
[20:52] <Jazzva> so, we can at least try? :)
[20:56] <fta> with a script, it requires low man power :)
[20:56] <Jazzva> at our side... there are testers that need to test it... I think that's mentioned on backport wiki page
[20:58] <fta> just create a ff-extension-backport ppa and push to there whenever you have a new release in ubuntu+1, this is quite easy to script
[22:38] <fta> asac, it crashes also when playing several video files with either totem or vlc plugins. The 1st video is fine, the 2nd crashes
[22:45] <fta> damn, xul trunk crash on startup
[22:49] <fta> my prism profile is corrupted :(
[23:23] <asac> fta: damn
[23:23] <asac> why is the crash not that frequent here
[23:23] <asac> hmm
[23:24] <asac> i could reproduce one flash on youtube
[23:24] <asac> but never after