[02:34] <[reed]> fta: ignore them
[02:34] <[reed]> Fx3 will be in RC stage by Hardy release
[02:34] <[reed]> so, good enough for me
[02:43] <CheGuevara> http://ubuntuforums.org/showthread.php?t=734176
[02:56] <CheGuevara> wow
[02:56] <CheGuevara> http://www.brewsters.co.uk/page4.html
[02:56] <CheGuevara> open that with ff3
[03:04] <[reed]> lol at that forum thread
[03:04] <[reed]> "I've just noticed beta5 is out. So should hit the repo's soon."
[03:10] <CheGuevara> yeah lol
[07:08] <saivann> asac : I will go to sleep and won't be there before ~6 hours, so I wanted you to be aware that I did not get emails from the ubuntu translator mailing list so far concerning ubufox translations. Thanks
[10:02] <asac> jtv: reminder ;)
[10:02] <jtv> asac: thanks
[10:03] <jtv> on call now, just a moment
[10:03] <asac> jtv: 1. en-US.xpi export, 2. access/control keys
[10:03] <asac> :)
[10:07] <jtv> asac: just discussed them with Carlos.  He's looking at them.
[10:09] <carlos> asac: I will need to talk with you once I finish my current call
[10:15] <asac> ok. i am here!
[10:15] <asac> carlos: welcome back, btw. hope you had a pleasant holiday.
[10:16] <carlos> asac: I'm ready too ;-)
[10:16] <carlos> asac: thank you. Yeah, it was great :-D
[10:17] <asac> carlos: ok. what info do you need?
[10:17] <carlos> asac: so, jtv just told me that you want something changed in the way we export .accesskey and .commandkey
[10:17] <asac> carlos: i want it to be exported like everything else ;)
[10:17] <carlos> I think we have a bug there, but from what I see, current behaviour fits what jtv told me that you wanted...
[10:17] <asac> whats the current behaviour?
[10:18] <carlos> from the files I sent to you is:
[10:18] <jtv> asac: carlos just looked at the German translation and found msgid "I" and msgstr "I"
[10:18] <carlos> #: firefox/en-US.xpi/en-US.jar!/locale/en-US/reporter/reportWizard.dtd(dontShowPrivacyStatement.accesskey)
[10:18] <carlos> msgid "I"
[10:18] <carlos> msgstr "I"
[10:18] <asac> right
[10:18] <asac> thats good
[10:18] <asac> unless "I" is not what is in the original reporteWizard.dtd
[10:18] <carlos> asac: what made you feel it was different?
[10:18] <jtv> asac: I neglected to download those exports I linked you to yesterday... what did you get in the translation files there?
[10:19] <asac> carlos: in every export jtv gave to me i saw msgid "dontShowPrivacyStatement.accesskey"
[10:19] <jtv> asac: that was the template though
[10:19] <asac> (not sure for this particular case, but for sure for other accesskey entities)
[10:19] <jtv> asac: and the "English translation," I gues
[10:19] <jtv> s
[10:20] <asac> jtv: why is that different in the template
[10:20] <asac> i would expect msgid "I" and msgstr ""
[10:20] <asac> let me check that
[10:20] <carlos> asac: something like:
[10:20] <carlos> #. Default key in en_US: 'I'
[10:20] <carlos> #: firefox/en-US.xpi/en-US.jar!/locale/en-US/reporter/reportWizard.dtd(dontShowPrivacyStatement.accesskey)
[10:20] <carlos> msgid "dontShowPrivacyStatement.accesskey"
[10:20] <carlos> msgstr "I"
[10:20] <carlos> ?
[10:21] <carlos> asac: this last bit is the one we are expected to export
[10:21] <asac> carlos: in "xulrunner/xulrunner-de.po"
[10:21] <asac> i have:
[10:21] <asac> #: en-US.xpi/en-US.jar!/locale/en-US/cookie/cookieAcceptDialog.dtd(button.allow.accesskey)
[10:21] <asac> msgid "button.allow.accesskey"
[10:21] <asac> msgstr ""
[10:21] <asac> #: en-US.xpi/en-US.jar!/locale/en-US/cookie/cookieAcceptDialog.dtd(button.session.accesskey)
[10:21] <asac> msgid "button.session.accesskey"
[10:21] <asac> msgstr ""
[10:21] <asac> thats in the exported translation for xulrunner from staging
[10:21] <carlos> that's more or less the expected value, except that for some reason the #. comment is not there
[10:22] <carlos> which provides the key used in en-US
[10:22] <asac> carlos: we certainly need the origina en-US there
[10:22] <asac> at least if msgstr is ""
[10:22] <carlos> Do you think that's more 'user friendly'?
[10:22] <asac> why is it treated differently at all?
[10:23] <carlos> asac: well, we thought it was easier to understand the shortcut key with the ID, instead of the key used in en-US
[10:23] <asac> carlos: i think its more user friendly for translators and for our po2xpi thing
[10:23] <carlos> I don't care about po2xpi right now for this case, but if you think users would understand it better in that other way, is quite easy for me to remove such functionality
[10:24] <carlos> I don't like any option
[10:24] <carlos> so I'm easy :-)
[10:24] <asac> carlos: how comes that you don't care for po2xpi ... if the info is not there then we cannot have po2xpi at all
[10:24] <asac> i mean ... everything we are doing is mostly because we want po2xpi
[10:24] <asac> (right now)
[10:25] <carlos> asac: what info is not there?
[10:25] <asac> the actual key
[10:25] <jtv> asac: I think what Carlos means is that this bit of code runs on import, so applies to online translation as well.
[10:25] <carlos> asac: as I said, that's a bug, there should be a line like: #. Default key in en_US: 'I'
[10:25] <carlos> so the info must be there
[10:25] <asac> carlos: if you say that for accesskeys its guaranteed to have a msgstr "" filled in, then its ok
[10:26] <carlos> I'm talking about how to present it to the users so it doesn't change once we move xpi exports inside launchpad
[10:27] <asac> i think you could also display the entity id as a comment ... and keep the actual key in msgid
[10:27] <carlos> asac: anyway, as I said, I'm going to handle that key in the same way as the other messages, because I don't like any option we have right now, and you think is better in the other way
[10:27] <asac> carlos: thanks. that would make sense imo
[10:28] <carlos> asac: well, no need to show it twice as a comment, it already appears in the file reference. Maybe add an explanation about what should be put there?
[10:28] <asac> carlos: will the translators see the entity id?
[10:29] <asac> (e.g. the comment)?
[10:29] <carlos> something like: 'Select the shortcut key that you want to use...' or something like that?
[10:29] <asac> carlos: that would be good. maybe we should put an advice in ther telling them to not change that if the imported translation already ships a key
[10:29] <carlos> asac: with current code, they should see it, yes
[10:29] <carlos> if they don't see it is a bug
[10:30] <asac> imo they should only touch those keys if there is not suitable localization setup at all
[10:30] <carlos> asac: that last part is more hard to achieve
[10:30] <carlos> but also possible
[10:30] <asac> its not a priority for me
[10:30] <asac> just because you asked about "what could be improved"
[10:30] <carlos> asac: sure, then, please, file bugs :-D
[10:31] <carlos> asac, jtv: For that comment to be show for all messages with such shortcut, any suggestion?
[10:31] <carlos> or just 'Select the shortcut key that you want to use'
[10:31] <asac> carlos: i think its fine for now
[10:32] <asac> remember that we still need things to improve for hardy+1 ... and we will certainly learn a lot from this during the next few weeks ;)
[10:32] <carlos> asac: or even better: 'Select the shortcut key that you want to use. Please, don't change this translation if you are not really sure about what you are doing'
[10:32] <jtv> carlos: fine, but you may want to check that you're not overwriting any existing comment when you do that.
[10:33] <carlos> jtv: I could append instead of setting
[10:33] <asac> carlos: actually we just need to make those translators aware of this fact that sign of translations i guess
[10:33] <jtv> carlos: exactly
[10:34] <asac> carlos: i found an entity currently not catched as "accesskey" : #: en-US.xpi/en-US.jar!/locale/en-US/cookie/cookieAcceptDialog.properties:9(detailsAccessKey)
[10:34] <carlos> asac: that message will appear in the exported .po files as a comment and also in our Launchpad UI
[10:34] <asac> carlos: thats good
[10:34] <carlos> asac: yeah, I think we have a bug there
[10:35] <asac> thats ok for hardy i guess.
[10:35] <asac> at least when we treat the .accesskey entities like discussed now
[10:35] <carlos> asac: I'm going to work on it today. Changing the way we handle messages should fix that, although it would produce that the comment is not used at all, so I still need to debug that problem
[10:36] <carlos> s/not used/not showed/
[10:36] <jtv> carlos: in TranslationImporter.importFile(), we copy TranslationMessageData.comment to TranslationMessage.comment, but not TranslationMessageData.source_comment to TranslationMessage.source_comment.  Could that be the cause of the missing comment?
[10:36] <carlos> jtv: indeed
[10:36] <carlos> jtv: good catch
[10:36] <asac> carlos: thanks. please try to get the en-US.xpi into the export if possible. that is really one of the bits that currently concerns me most.
[10:37] <asac> the workarounds to deal with the lack of that file would be really, really hacky
[10:37] <asac> and error-prone i guess
[10:37] <carlos> yeah, those two tasks are in my todo list for today
[10:37] <asac> jtv: the export i did yesterday didn't contain any actual translations, right? you said you had the importer still running ... did you reexport them?
[10:37] <jtv> asac: it did contain a few.
[10:37] <asac> jtv: but just for firefox?
[10:38] <asac> i am looking at xulrunner-de.po and dont see any
[10:38] <jtv> asac: no, both
[10:38] <asac> maybe you didn't import twice?
[10:38] <asac> hmm
[10:38] <jtv> asac: the upload wasn't completed, so maybe it's just that German happened not to be in there.
[10:38] <asac> jtv: right... there are others that have translations
[10:39] <jtv> If you request a German translation when we have a template without a German translation, we generate one on the fly.
[10:39] <asac> like -it + -ko
[10:39] <asac> jtv: the format of xulrunner-it.po looks busted
[10:39] <jtv> !?
[10:39] <jtv> In what way?
[10:39] <asac> ah, sorry ... its just that in the beginning there are entities i haven't seen before:
[10:40] <asac> jtv: http://paste.ubuntu.com/6054/
[10:40] <asac> jtv: http://paste.ubuntu.com/6055/
[10:40] <carlos> asac: those are obsolete entries
[10:40] <asac> some of the form of 6054 and others are correct like 6055
[10:40] <asac> carlos: ah ok
[10:40] <carlos> asac: I removed them from the files I sent you
[10:40] <asac> so those are the ones that are just in firefox
[10:41] <asac> ok thats good then
[10:41] <carlos> asac: and those should be completely ignored
[10:41] <jtv> carlos: thanks... my eyes just filtered out the "#~" at the beginning of each line
[10:41] <asac> our parser should be able to deal with that
[10:41] <jtv> asac: it should treat them as comments anyway
[10:41] <carlos> jtv: btw, we have a bug, because #~ must be at the end of the file
[10:41] <asac> yes, i think its ok for the current algorithm we have ... if not thats a bug in our po2xpi parser
[10:41] <jtv> carlos: really?  I think we always have them at the beginning...
[10:41] <jtv> carlos: maybe because sequence == 0?
[10:41] <carlos> jtv: I guess it's because sequence is 0
[10:42] <carlos> jtv: yeah
[10:42] <carlos> jtv: for some reason, we got a regression
[10:42] <jtv> carlos: we should've set sequence to NULL, but None < 0 too.  :-)
[10:42] <carlos> but is nothing new, I think I saw it a while ago...
[10:42] <jtv> carlos: I'll file a bug.  Not very urgent.
[10:42] <carlos> jtv: right
[10:42] <jtv> Just remember to fix the comments as part of your branch!
[10:42] <asac> ack ... not urgent from my point of view either
[10:43] <jtv> carlos: oh, and to avoid conflicts, get the latest RF so my changes to the XPI importer are included.
[10:44] <carlos> jtv: I need to start a new branch, so I was planning to do that anyway :-)
[10:45] <jtv> carlos: well, cd trunk && bzr pull just to be sure.  :)
[10:57] <jtv> carlos: it's not a regression but an unfixed known bug: bug 17353
[10:57] <ubotu> Launchpad bug 17353 in xorg "Xorg fails to start due to broken symlink" [Critical,Fix released] https://launchpad.net/bugs/17353
[10:57] <jtv> Ahem, nbot that one :)
[10:58] <jtv> s/nbot/not/
[10:58] <carlos> jtv: :-)
[10:58] <jtv> bug 173530
[10:58] <ubotu> Launchpad bug 173530 in rosetta "Obsolete strings at the top of exported files" [Undecided,New] https://launchpad.net/bugs/173530
[10:58] <jtv> Yeah!  Got it in two!
[10:58] <carlos> jtv: well, it was a regression when the bug was filed :-)
[10:59] <jtv> reregression
[11:10] <asac> i had a reconnect about ten minutes ago - just in case you asked something :)
[11:15] <armin76> asac: http://paste.ubuntu.com/6056/
[11:17] <asac> armin76: thx
[11:21] <asac> jimmy_: there? ill push the 3.0 beta3 merge to a new branch called "merge.3.0b3" ... please test for any regressions before i go ahead with beta 4 merge
[11:25] <asac> jimmy_: done
[12:59] <salty-horse> hi. who's responsible for the "ubuntu firefox modifications" extension?
[13:00] <salty-horse> and where do I file bugs about it?
[13:59] <Hssn> you know that www.youtube.com is filtered here but uk.youtube.com or ca. ones are not filtered. the probelm is that I can reach these site in windows but not in Ubuntu. with the same ADSL account & same version of firefox and extesion. nothing happend when I enter uk.youtueb.com. have any idea?
[14:01] <salty-horse> Hssn, using the same proxy settings?
[14:02] <Hssn> there is no proxy setting. direct connect to internet. (if you mean proxy setting in firefox)
[14:08] <salty-horse> hmm.. I don't know then :)
[14:08] <salty-horse> oh
[14:08] <salty-horse> try changing the user-agent
[14:08] <salty-horse> with this: http://chrispederick.com/work/user-agent-switcher/
[14:10] <Hssn> ok, thank you
[14:13] <salty-horse> ... now I won't know if it worked
[14:19] <fta2> lo
[14:38] <jussi01> Hei all, I have a quick question about whether a bug is ubuntu's or mozillas.
[14:39] <jussi01> Im on hardy, and firefox3 does not automatically associate files with programs, ie. open offfice files with open office. is that ubuntu's bug or mozilla's or both? best to report it on lp?
[15:34] <asac> jussi01: yes
[15:34] <asac> report on launchpad
[15:34] <jussi01> ok
[15:34] <jussi01> will do
[15:34] <asac> and suggest a suitable
[15:34] <asac> bugzilla.mozilla.org bug id in the LP bug
[15:34] <asac> we will then take a look
[15:35] <jussi01> sure
[15:35] <asac> salty-horse: please file bugs in launchpad
[15:35] <asac> and if they are important prod me with the bug id in here ;)
[15:36] <salty-horse> asac, under what ... category?
[15:36] <asac> against the ubufox package
[15:36] <asac> bugs.launchpad.net/ubuntu/+source/ubufox
[15:36] <asac> there -> report a bug
[15:36] <asac> salty-horse: ^^^
[15:37] <salty-horse> I got two issues: 1) in the plugin selection window, the firefox progress bar (from the previous step) is showing through. 2) when looking for java, ubuntu should recommend icedtea-gcjwebplugin (it currently recommends nothing)
[15:37] <salty-horse> I'll file them later today
[19:26] <asac> ok ... hope thats it for this security round
[19:42] <salty-horse> asac, I think build.sh in ubufox can use sh instead of bash. It'll be faster :)
[19:42] <asac> salty-horse: haha ... and that would really be a win?
[19:43] <salty-horse> It'll be more elegant
[19:43] <salty-horse> but it doesn't make a difference, really :)
[19:43] <asac> i doubt that it really matters, but feel free to bring up a topic branch to improve build.sh
[19:43] <asac> i will merge it if its good
[19:45] <salty-horse> naa.. it doesn't really matter :)
[19:45] <asac> lol
[19:45] <asac> sounds a bit like "words are cheap"
[19:45] <asac> :-P
[19:46] <salty-horse> what does searchplugins/ask.xml do? it's not registered automatically in the search box, and no code in the extension references it
[19:46] <asac> its registered for me
[19:46] <asac> (in firefox 3 at least)
[19:46] <salty-horse> asac, I made the change locally, but it's silly to publish just for that :)  and if you get a new version of build.sh from the source, it will be gone
[19:47] <salty-horse> oh, I'm on the nightly build.. not the ubuntu-supplied beta4 :/
[19:47] <asac> salty-horse: he?
[19:47] <asac> you can just commit and push the branch ... i can then merge in
[19:47] <asac> its even easier than applying a diff for me
[19:47] <salty-horse> ok. I'll see if I can fix the other issues too
[19:47] <salty-horse> does bzr track file permissions?
[19:47] <asac> salty-horse: which other issues?
[19:47] <asac> salty-horse: yes.
[19:48] <asac> salty-horse: if you work on "upstream" issues, work against _my_ main branch: https://code.edge.launchpad.net/~asac/ubufox/main
[19:49] <salty-horse> from before: <salty-horse> I got two issues: 1) in the plugin selection list dialog, the firefox progress bar (from the previous step) is showing through (it turns the dotted focus outline to white). 2) when looking for java, ubuntu should recommend icedtea-gcjwebplugin (it currently recommends nothing)
[19:49] <asac> salty-horse: 1) -> this needs a bit more coding as you need to decouple the installer invocation from the UI thread
[19:49] <asac> 2) this requires an update run of the plugin finder DB
[19:49] <asac> there is nothing you can do about it
[19:50] <asac> if the icedtea-gcjwebplugin provides the proper Npp- headers in control it will be automatically updated on next sync of plugin finder DB
[19:50] <salty-horse> asac, I am using your branch. lp:ubufox conveniently points to it
[19:50] <asac> salty-horse: if you want to work on 1) i can provide you pointers
[19:50] <salty-horse> I'll check the plugin first :)
[19:50] <asac> let me see
[19:51] <asac> yes appears to be the right branch
[19:51] <asac> find
[19:51] <asac> fine
[19:52] <asac> salty-horse: 1) is only possible to fix in ffox 3 ... so you need to special case this (just so that you know in advance ) :)
[19:52] <salty-horse> ok, the java plugin has "Xb-Npp-MimeType: application/x-java-vm, [...]"
[19:56] <asac> salty-horse: yes. so it will be fixed soonish
[20:03] <salty-horse> asac, I'll leave build.sh as it is since it's forked from http://kb.mozillazine.org/Bash_build_script
[20:04] <asac> as you wish
[20:04] <fta> [reed], a user in the forum said that the latest nightly is now faster than my lastest debs; while they were almost equal a few days ago. The jemalloc bug ?
[20:04] <fta> [reed], I've asked for figures, and methodology..
[20:04] <asac> fta: didn't you back that patch out?
[20:05] <asac> (in favour of dropping symbolic-functions)
[20:05] <fta> yes, i've done that
[20:05] <asac> then i doubt that thats the reason
[20:32] <jimmy_> asac: why aren't we doing beta4?
[20:36] <asac> jimmy_: just because i had that ready already
[20:36] <asac> next is beta4
[20:37] <asac> just would like to confirm that we haven't lost anything before moving ahead
[20:37] <asac> jimmy_: ill work on beta4. would be nice if you could see if beta3 has any regression against the current master head
[20:37] <asac> i merged everything from today on the merge branch i had ... so i hope that everything is there
[20:39] <jimmy_> ok, i'll check with Carl
[20:40] <jimmy_> btw, do you know how to get a total line count for all the source files?  wc -l doesn't work well for subdirectories
[20:41] <salty-horse> jimmy_, use ack (http://petdance.com/ack/) to get the file list, then xargs wc -l
[20:41] <jimmy_> salty-horse: thanks, doesn't that produce a line count for each file?  will it get me the total # of lines?
[20:51] <asac> jimmy_: no idea ... i am not line-count-fetish ;) ... i think for a sourceball of the size of mozilla it makes more sense to measure in MB :)
[20:51] <asac> MB of unpacked sources ;)
[20:52] <jimmy_> asac: LOL, i'll dig around to see if there's a simple tool or script
[20:53] <asac> yep
[20:54] <salty-horse> jimmy_, xargs will give wc as files as it can in one call, so you *may* get a total. if not, run xargs with -n 1, and sum it up yourself with awk '{sum+=$0} END {print sum}' :)
[20:54] <salty-horse> oops. that's $1
[20:57] <jimmy_> salty-horse: all files in 1 call? how scalable is that say if i pass in everything in the mozilla directory?
[20:58] <salty-horse> let's see...
[21:01] <salty-horse> mozilla has xul files. ack doesn't search them by default:
[21:02] <fta> find xulrunner-1.9-1.9~b5~cvs20080324t1000+nobinonly/ -type f | xargs wc -l | grep -E ' total$' | perl -ne 'm/(\d+)/; $num += $1; END { print "Total = $num\n" }'
[21:02] <fta> Total = 6075175
[21:02] <salty-horse> $ ack -f --type-add xul=.xul | xargs -n 1 wc -l | awk '{sum += $1} END {print sum}'
[21:30] <jimmy_> salty-horse: cool, thanks a lot
[21:30] <salty-horse> did you time it? :)
[21:46] <salty-horse> jimmy_, check out http://labs.ohloh.net/ohcount
[21:49] <jimmy_> salty-horse: that's handy :)
[21:50] <salty-horse> jimmy_, and of course, they already scanned mozilla: http://www.ohloh.net/projects/9/analyses/latest
[21:54] <armin76> http://www.wbbm780.com/pages/1882912.php <- this is asac
[21:54] <armin76> *g*
[23:22] <Fujitsu> Why do we still have the iceape sources in Hardy? There is quite a number of vulnerabilites, and seamonkey seems to now provide all of the iceape* binaries.
[23:30] <fta> do we ?
[23:30] <fta> !info iceape hardy
[23:30] <Fujitsu> It's still there.
[23:31] <Fujitsu> Same version as Gutsy. There have been no security updates.
[23:31] <Fujitsu> I presume it's a mistake.
[23:31] <fta> iceape is a dummy transition package to seamonkey
[23:32] <Fujitsu> The binaries are.
[23:32] <fta>     iceape | 1.1.4-1ubuntu2 | http://archive.ubuntu.com hardy/universe Sources
[23:32] <fta>  seamonkey | 1.1.8+nobinonly-0ubuntu1 | http://archive.ubuntu.com hardy/universe Sources
[23:32] <fta> oh damn
[23:32] <Fujitsu> Yes.
[23:32] <Fujitsu> The source is still there.
[23:32] <fta> then it should be removed
[23:32] <Fujitsu> I don't think it has any binaries published, as they're all provided by seamonkey.
[23:32] <Fujitsu> Shall I request it?
[23:33] <fta> yes, please
[23:33] <fta> same for the auto sync/merge, if any
[23:33] <Fujitsu> THanks.
[23:33] <fta> i should package seamonkey 1.1.9 shortly
[23:33] <Fujitsu> That fixes some security issues?
[23:34] <fta> yes
[23:34] <Fujitsu> I see 7 CVEs open against seamonkey in Hardy.
[23:34] <fta> and I will add the long due apport bug
[23:35] <Fujitsu> What's happening with xulrunner and firefox? They both have more than a dozen open CVEs.
[23:36] <fta> which versions ? 1.8 / 2.0 or 1.9 / 3.0 ?
[23:36] <Fujitsu> The former.
[23:37] <fta> my guess is xulrunner 1.8.* is not needed anymore, at least it should no longer be a dep/builddep of anything
[23:37] <fta> and ff2, asac has it in QA right now
[23:38] <fta> but we can do xul 1.8 too if it's needed
[23:38] <Fujitsu> The java plugins seem to depend on xulrunner.
[23:38] <Fujitsu> Oh.
[23:38] <Fujitsu> It's an |, so that's fine.
[23:41] <fta> http://www.asoftsite.org/s9y/archives/131-guid.html
[23:41] <fta> here is ff2
[23:41] <fta> or here http://mozilla.qa.ubuntu.com/
[23:55] <Fujitsu> fta: If you can get a firm answer on what we want to do with xulrunner, it'd be very useful. Once iceape is gone, it'll be the Free package with the most open security issues in Hardy.
[23:56] <fta> asac, you here ?
[23:56] <fta> Fujitsu, I'll discuss with asac and let you know
[23:56] <asac> fta: i should be in bed, but yes.
[23:56] <fta> oh
[23:57] <fta> do we still need xul 1.8 in hardy ?
[23:57] <asac> i think so
[23:57] <asac> there are probably still rbuilddepends
[23:57] <asac> in universe
[23:57] <Fujitsu> Indeed, there are a few :(
[23:57] <asac> if thats not the case we can dump it
[23:58] <asac> well, we should update it
[23:58] <asac> at least now ... to fix the current security issues
[23:58] <fta> I'll do that with seamonkey, probably tomorrow
[23:58] <Fujitsu> Thanks.