[00:15] <Jazzva> asac: It happend to me on youtube a lot ... well, not a lot, but it was frequent...
[00:15] <Jazzva> or at some local newspapers' site, on a page with embedded flash video
[01:30] <Jazzva> Off to bed... head and neck hurt a lot... asac, please take a look at foxyproxy bug report for review :). That is, if it can still get to the archives. bug 212875
[01:30] <ubotu> Launchpad bug 212875 in foxyproxy "REVIEW/SPONSOR: please review and sponsor foxyproxy" [Undecided,New] https://launchpad.net/bugs/212875
[08:59] <asac> carlos: maybe, the points we discussed yesterady hide other minor issues, but for now it looks like that those are still the ones that are important.
[09:00] <carlos> ok
[09:00] <asac> my script for processing translation packs to distro packs is more or less ready btw ;)
[09:01] <asac> carlos: i have one more question.
[09:01] <asac> we face the problem that our browser will not be final for release
[09:01] <asac> even though i hope that no new strings are added, it might happen.
[09:02] <asac> now in case we need to update in hardy, we need language packs at the same time. so my question is:
[09:02] <asac> can we still upload templates (en-US.xpI) manually<0
[09:02] <asac> ?
[09:02] <carlos> yes
[09:02] <carlos> however, I understand that you will still upload a new source package
[09:02] <asac> ok ... so in theory i could upload en-US:xpi manually 2 weeks before release and have the language pack tarballs like 3 days ahead of release, right?
[09:03] <carlos> which should produce an en-US.xpi file to be uploaded into Launchpad automatically
[09:03] <asac> (this will most likelyl only be required for one update)
[09:03] <carlos> ah!
[09:03] <carlos> that
[09:03] <carlos> yeah, that's possible
[09:03] <carlos> however, language packs timing depend on pitti
[09:03] <carlos> not me
[09:03] <asac> ok ... point is i can produce en-US.xpi for a release two weeeks ahead, but i can't upload two weeks ahead
[09:03] <carlos> so you should coordinate that with him
[09:03] <asac> carlos: yeah ... the distro side, right
[09:04] <carlos> I'm not sure whether 3 days ahead of release will be possible to get language packs .deb packages uploaded...
[09:04] <asac> carlos: is it possible to get po files exported separately in case we find we cannot include them in the main translation pack for the above reasons?
[09:04] <carlos> pitti asks for some testing before that happens
[09:05] <asac> hmm
[09:05] <asac> right
[09:05] <asac> i have to talk to him
[09:05] <carlos> asac: yeah, except for the en-US.xpi file. However given that that will be a manual process, I guess is not a problem and that you could provide it anyway
[09:05] <asac> but could we - in theory - export the xul + ffox .po files in a separate tarball?
[09:05] <carlos> yes
[09:05] <asac> (e.g. so i could use them to package it the old lame way)
[09:05] <carlos> just without the .xpi file
[09:06] <asac> carlos: i think not having en-US.xpi would be fine, is it such a hack?
[09:06] <carlos> well, the 'hack' is what we do in language packs
[09:07] <carlos> we could provide it in such exports (only firefox and xulrunner) if you want
[09:07] <carlos> but not this month
[09:07] <asac> yeah ... just wondered how hacky the inclusion of en-US.xpi would be
[09:07] <carlos> it's easy, is just that for that other use case we didn't think it would be useful
[09:07] <carlos> so we don't export it
[09:07] <asac> carlos: ill discuss with bitty. if we need the separate option it would be great to have them in ... so they are self-sustaining
[09:07] <asac> s/bitty/pitti/ :(
[09:08] <asac> carlos: ok. so now i have the big issue that beta5 en-US.xpi have not been uploaded. do you have any idea on that?
[09:08] <carlos> asac: you are able to get such exports right now: https://translations.launchpad.net/ubuntu/hardy/+source/firefox-3.0/+export and https://translations.launchpad.net/ubuntu/hardy/+source/xulrunner-1.9/+export
[09:09] <carlos> asac: I think is a bug in our side of the chain
[09:09] <asac> such? do you mean already with en-US.xpi ?
[09:09] <carlos> asac: I can manually import it though
[09:09] <carlos> do you have the .xpi files?
[09:09] <asac> carlos: no not anymore ... i have to do a respin to get them ;)
[09:10] <carlos> asac: ok, maybe I can get it from some other place...
[09:10] <asac> but i plan to do that anyway
[09:10] <asac> carlos: hmm
[09:10] <carlos> asac: when was the package built?
[09:10] <asac> maybe you still have the tarballs so we can at least verify that they were included
[09:10] <asac> ?
[09:10]  * asac looking
[09:11] <carlos> found
[09:11] <asac> 2008-04-05 (ffox 3 beta5)
[09:11] <carlos> :-P
[09:11] <asac> xul too
[09:11] <asac> ok
[09:11] <asac> great
[09:11] <asac> is it in?
[09:11] <carlos> hmm
[09:11] <carlos> xulrunner is there
[09:11] <carlos> firefox is not
[09:11] <asac> huh?
[09:11] <carlos> so I think firefox extraction didn't work
[09:11] <asac> what do you mean? the en-US.xpi is missing?
[09:12] <asac> let me look at build log
[09:12] <carlos> asac: there is no translations tarball for firefox
[09:12] <carlos> however, there is one for xulrunner
[09:12] <asac> carlos: i think this time the en-US.xpi has no install.rdf ... is that a problem for your importer?
[09:13] <carlos> hmm, not sure... maybe... however, that's not a reason for not seeing the en-US.xpi file
[09:14] <carlos> asac: I just uploaded an update for xulrunner, however, it will take a while to get it imported (the queue is a bit busy right now with oo.org...)
[09:15] <asac> sure
[09:15] <asac> i will figure whats going on for the translation tarball
[09:16] <asac> carlos: firefox couldn't produce one indeed
[09:16] <asac> no error though
[09:18] <carlos> maybe a missing rule?
[09:18] <asac> no its produced
[09:18] <asac> the translation thing doesnt pick it u
[09:18] <asac> mkdir -p debian/lp-export-xpis/en-US.xpi-flat
[09:18] <asac> # extract locale filenames from $(MOZCALL_all_manifests) and
[09:18] <asac> # move the files to $(MOZCALL_manifest_locale_files_to_outdir)
[09:18] <asac> # produce chrome.manifest for all locale entries adding: en-US.jar (deflated 73%) adding: chrome.manifest (deflated 60%)
[09:18] <asac> rm -rf debian/lp-export-xpis/en-US.xpi-flat/
[09:18] <asac> thats what is done
[09:19] <asac> carlos: oh
[09:19] <asac> i see the tarball _is_ produced
[09:19] <asac> pkgstriptranslations: preparing translation tarball firefox-3.0_3.0~b5+nobinonly-0ubuntu1_i386_translations.tar.gz...done (1 files)
[09:20] <asac> carlos: is that tarball nowere?
[09:20] <asac> http://launchpadlibrarian.net/13136118/buildlog_ubuntu-hardy-i386.firefox-3.0_3.0~b5%2Bnobinonly-0ubuntu1_FULLYBUILT.txt.gz
[09:20] <asac> thats the build log
[09:31] <carlos> asac: I can only think on getting help from pitti...
[09:33] <asac> carlos: i have asked him
[09:33] <asac> will let you know
[09:36] <carlos> ok, thanks
[09:51] <asac> Jazzva: ok ill go through the final extension submissions today
[09:51] <asac> Jazzva: after that we have to update the extension install dialog to contain the latest
[09:52] <Jazzva> asac: Ok...
[09:52] <Jazzva> you mean the app-install-data package with new .desktop files?
[09:52] <asac> yeah
[09:53] <asac> you did that in last cycle too right?
[09:53] <Jazzva> Yep ...
[09:53] <Jazzva> I can do it tonight, if it's ok... :)
[09:55] <asac> sure
[09:55] <asac> mozgest failed because of missing zip build-dependency
[09:56] <Jazzva> I think I almost let one without zip dep, then I remembered and corrected ...
[10:07] <asac> ;)
[10:11] <Jazzva> btw, FF is buggy for me ... It seems to crash on few login screens too... It happened when I saved two username/password combinations. Then it just closes when I open that page...
[10:11] <Jazzva> I think it (still) crashes when I go to "Show passwords" dialog in Preferences
[10:12] <Jazzva> yep ...
[10:15] <Jazzva> It seems to be related to saved passwords... I have just deleted the signons3.txt and key3.db and it's fine ...
[10:16] <asac> hmm
[10:16] <Jazzva> hmm ... tried to reproduce, but nothing...
[10:17] <asac> you probably don't have the old files anymore?
[10:17] <Jazzva> no ...
[10:17] <Jazzva> deleted them few minutes ago :(
[10:18] <Jazzva> ah
[10:18] <Jazzva> it crashed
[10:18] <Jazzva> what do you need from files?
[10:18] <asac> Jazzva: extension problem?
[10:19] <asac> try to disable them one by one
[10:19] <asac> or first with -safe-mode
[10:19] <asac> to see if it helps
[10:19] <Jazzva> Ok
[10:20] <Jazzva> died
[10:20] <Jazzva> just when it started opening the login page...
[10:21] <Jazzva> does it fetch some login data at that point? (like stored usernames)
[10:21] <Jazzva> It happened with clear profile, too... Well, two clear profiles :)...
[10:22] <Jazzva> s/clear/clean/
[10:22] <asac> yes it tries to gather whether login data is stored at that point
[10:22] <asac> which site?
[10:22] <Jazzva> this one is wiki.ubuntu.com
[10:23] <Jazzva> and the other is for joomla control panel
[10:23] <asac> Jazzva: which libnss* version?
[10:23] <Jazzva> the latest from fta's repo
[10:23] <Jazzva> *ppa
[10:23] <asac> plese look
[10:24] <asac> tell me the version ;) they might be out of sync with what is really the latest as fta had some version screw in his archive
[10:24] <Jazzva> 3.12.0~cvs20080404t1842-0ubuntu1~fta1
[10:24] <Jazzva> Oh
[10:24] <asac> that sounds old :)
[10:24] <Jazzva> 0404
[10:24] <Jazzva> Yep ...
[10:24] <asac> latest nss he has is cvs20080407t0003-0ubuntu1
[10:25] <asac> but i'd suggest first to downgrade to hardy version and see if all is ok ;)
[10:25] <Jazzva> Hmm, ok
[10:28] <Jazzva> just libnss, or firefox package too?
[10:28] <Jazzva> asac^
[10:28] <Jazzva> asac ^
[10:30] <asac> Jazzva: i'd suggest everything
[10:30] <Jazzva> ok
[10:30] <asac> but maybe see if the crashes go away with latest nss
[10:30] <asac> first
[10:31] <Jazzva> downgrading already... I'll go with this first :)
[10:31] <asac> remember xulrunner needs to be downed too
[10:36] <Jazzva> It will take a while... few minutes
[10:51] <Jazzva> seems to be fine with ff and the rest from hardy's repo
[10:51] <Jazzva> I will update back to fta's repo
[10:53] <asac> ok ... good to know
[10:53] <Jazzva> hmm, forgot to downgrade libnspr
[10:53] <Jazzva> but it worked
[10:53] <asac> yeah
[10:53] <asac> nspr is rather stable piece of software
[10:56] <Jazzva> asac, in the meantime, have you corrected the xpi.template? debian/rules: MOZ_EM_ID => MOZ_XPI_EMID (that's the name of the var in xpi.mk) and maybe something else
[10:57] <asac> oh
[10:57] <asac> let me do that
[10:57] <Jazzva> Oh
[10:57] <Jazzva> and
[10:57] <Jazzva> debian/changelog: Closes: #... => LP: #...
[10:58] <Jazzva> that's what I wrote down... and now I remembered
[10:58] <Jazzva> maybe we should use ~ubuntu-dev in Vcs-Bzr from the start ... :)
[10:59] <asac> yea
[10:59] <Jazzva> :)
[11:00] <asac> Jazzva: the ~ubuntu-dev thing i already did yesterady
[11:00] <asac> doing the rest now
[11:00] <Jazzva> Ok...
[11:01] <Jazzva> heh... ff3 crashed when I clicked on "Login" on wiki.ubuntu.com
[11:01] <Jazzva> (update to fta's repo)
[11:01] <Jazzva> With the same profile I used with hardy's version...
[11:02] <asac> Jazzva: ok i pushed the changes to XPI.TEMPLATE to bzr
[11:02] <asac> maybe look if you see anything else
[11:02] <Jazzva> great
[11:02] <asac> i also use XSBC- and Maintainer split and ubuntunized the package revision in changelog
[11:03] <Jazzva> I will ... I'll downgrade back to hardy's again ... Sis is gonna use it in the afternoon, don't wanna her bump into troubles :).
[11:03] <Jazzva> xpi.template is in mozillateam's branch?
[11:04] <asac> yes
[11:04] <asac> revision 7
[11:04] <asac> Jazzva: ^^^
[11:04] <Jazzva> Branching
[11:04] <Jazzva> done
[11:04] <asac> hmm still rev 6 on launchpad
[11:05] <asac> ah now
[11:05] <Jazzva> hmm, branched rev7
[11:05] <asac> ok
[11:05] <Jazzva> Haven't noticed this before
[11:05] <asac> yeah then you had luck ;)
[11:05] <Jazzva> Vcs-Bzr branch is used for branching, right?
[11:05] <asac> yes
[11:06] <asac> you can use whatever you want though ;)
[11:06] <Jazzva> Should it be then "http://bazaar..." instead of "https://code..."
[11:06] <Jazzva> Oh :)...
[11:06] <Jazzva> ok :)
[11:06] <asac> no code works well and you can open that in a browser
[11:07] <asac> thus i think we should keep code.
[11:07] <Jazzva> right ... ok :)
[11:07] <asac> isn't that what is in control=
[11:07] <Jazzva> https://code...? yes
[11:07] <asac> yeah
[11:07] <asac> looks ok
[11:08] <Jazzva> Looks fine to me..
[11:08] <asac> thx
[11:09] <Jazzva> oh, debian/changelog: Alexander Sac <...> as submitter, or Yourname <your@email.tld>?
[11:09] <Jazzva> *Sack
[11:10] <asac> Jazzva: fixed
[11:11] <Jazzva> :)
[11:12] <Jazzva> Time in changelog isnt' a big deal?
[11:12] <Jazzva> *isn't
[11:12] <Jazzva> I'm not sure...
[11:13] <asac> no idea how to fix that in a generic fashion
[11:13] <asac> maybe we should add content to the changelog entry that describes that you should run dch -r before relese with DEBEMAIL=your@email.tld
[11:13] <Jazzva> Yep... that's why I think it's not a big deal... since it must comply to a certain format, no idea how to put it simply to new packagers...
[11:14] <Jazzva> Hmm... sounds good
[11:14] <asac> ill think
[11:14] <Jazzva> k :)
[11:21] <asac> Jazzva: http://paste.ubuntu.com/6609/
[11:21] <asac> is that comprehensible for you?
[11:22] <asac> some typos left
[11:23] <asac> http://paste.ubuntu.com/6610/
[11:24] <Jazzva> yep, sounds ok...
[11:25] <Jazzva> maybe to replace "after upload you start" with "after upload to the archives you start"
[11:25] <Jazzva> So it won't be assumed as "upload to the branch"
[11:26] <Jazzva> But, maybe that's just me :)...
[11:27] <asac> Jazzva: maybe "after release"
[11:27] <asac> this implies that you don#t have to wait for someone to upload in case you don't have the powers
[11:27] <Jazzva> I suppose ...
[11:27] <Jazzva> :)
[11:37] <Jazzva> I'm off (school)... Will be back in the evening...
[12:03] <asac> fta: why do we ship reporter?
[13:04] <carlos> asac: hi
[13:05] <carlos> asac: I have an answer for the problem you found when we were showing the id instead of the English value
[13:05] <carlos> asac: the problem is in the en-US.xpi, so we do exactly what is expected
[13:05] <carlos> intl.charset.default=ISO-8859-1
[13:05] <carlos> intl.charset.detector=
[13:05] <carlos> intl.charsetmenu.mailedit=ISO-8859-1, ...
[13:06] <carlos> asac: that's what we have in the en-US.xpi file
[13:06] <carlos> and that's why we show directly 'intl.charset.detector' instead of an English string or value
[13:16] <asac> carlos: those accesskey-XXX things definitly exist
[13:16] <asac> not sure about the charset dector
[13:16] <asac> but if its empty it should stay empty
[13:16] <asac> not insert the key
[13:17] <carlos> ok, maybe I choose the wrong example :-P
[13:17] <carlos> let me check for the others...
[13:17] <asac> carlos: look for accesskey-done
[13:17] <carlos> asac: well, we do that to help translators
[13:17] <carlos> asac: it shouldn't be an issue for you
[13:17] <carlos> asac: you don't rebuild the en-US.xpi file
[13:18] <asac> carlos: thats an issue
[13:18] <asac> i use that value if there is no translation
[13:18] <asac> anyway ... look at the ones that exist
[13:18] <carlos> well
[13:19] <carlos> that's a technical problem we cannot fix ever without rebuilding Launchpad translations
[13:19] <carlos> so may I suggest you a workaround?
[13:19] <carlos> don't use it if it matches the ID...
[13:19] <asac> carlos: 516 in xulrunner-1.9 (look in erman)
[13:19] <asac> accesskey-accept
[13:20] <asac> 517: accesskey-cancel
[13:20] <carlos> asac: why should I check German? we msgids come from en-US
[13:20] <carlos> s/we/the/
[13:20] <asac> carlos: yeah ... thats just where i am ;)
[13:20] <asac> you can look everywhere
[13:21] <asac> carlos: ok i think i can implement that hack
[13:21] <carlos> asac: again, it's an en-US.xpi fault
[13:21] <carlos> button-accept=OK
[13:21] <carlos> button-cancel=Cancel
[13:21] <carlos> button-help=Help
[13:21] <carlos> button-disclosure=More Info
[13:21] <carlos> accesskey-accept=
[13:21] <asac> lets hope that the text doesn't match the key somewhere
[13:21] <carlos> accesskey-cancel=
[13:21] <carlos> accesskey-help=
[13:21] <asac> ok
[13:21] <carlos> accesskey-disclosure=
[13:21] <asac> ill see how far i get then
[13:22] <carlos> ok
[13:22] <carlos> btw, all other fixes are implemented and tested. I'm waiting for the QA process to get it rolled out to production
[13:23] <asac> carlos: great. can i give you a en-US.xpi for xul and ffox that have the final form?
[13:23] <asac> for beta 5 ;)
[13:23] <asac> carlos: did you say that i can get the en-US.xpi in project translation exports as well?
[13:24] <carlos> yeah, but not this month
[13:24] <carlos> I mean
[13:24] <carlos> not until the end of this month
[13:24] <carlos> that's not something critical
[13:25] <carlos> so is hard to me to get an approval for it
[13:26] <asac> ok
[13:26] <asac> carlos: http://people.ubuntu.com/~asac/xpis-xul+ffox-b5.tar.gz
[13:26] <asac> let me take a final look if they are good ;)
[13:27] <carlos> asac: and the URL for the translations?
[13:28] <asac> carlos: http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.0b5/linux-i686/xpi/
[13:28] <asac> carlos: do you recognize the lang codes (its - not _ )
[13:28] <asac> e.g. for es-AR.xpi?
[13:29] <carlos> asac: well, I had to approve it initially by hand
[13:29] <carlos> but we are adding support for that
[13:29] <carlos> so you get it back on export
[13:29] <carlos> right now... as you saw you don't get those with those codes...
[13:29] <carlos> so zh-TW becomes zh_TW
[13:29] <asac> yes thats not a problem on my side
[13:29] <carlos> but we have an open branch to give you back zh-TW
[13:29] <asac> just wonder if you properly process that on translation import
[13:29] <carlos> for firefox is not a big issue, we have extra manual work to do
[13:30] <asac> carlos: you don't need to deal with that ... the _ -> - replacement belongs in the .po2xpi thing anyway imo
[13:30] <carlos> but with oo.org is much worse
[13:30] <carlos> so we are doing a proper fix
[13:30] <asac> ok
[13:30] <carlos> asac: we need to do that when we start producing the .xpi ourselves :-P
[13:31] <asac> carlos: well ... the software for po2xpi is available you can just take that i guess
[13:31] <asac> once all issues are flashed out
[13:31] <carlos> sure, that will be wonderful
[13:32] <carlos> btw, the b5 upload will take a while
[13:32] <asac> how many days?
[13:32] <carlos> the import queue is a bit busy with oo.org processing
[13:32] <asac> you think any chance to get the exports tomorrow morning?
[13:32] <carlos> I hope not more than 1 day...
[13:32] <asac> ok
[13:32] <carlos> hmm, not sure about that...
[13:32]  * asac crosses fingers
[13:33] <carlos> I'm uploading everything, so it will be ready to be imported as soon as we clear the queue a bit
[13:35]  * carlos -> lunch
[15:13] <asac> folks cairo is borked ... so don't upgrade ;)
[15:14] <asac> and teach the forums about that
[15:14] <asac> ;
[15:14] <asac> ;)
[15:14] <asac> fta: ^^
[15:45] <armin76> what cairo?
[15:46] <asac> today they roll a new tarball
[15:46] <asac> armin76: latest
[15:50] <asac> cwong1: could you get jimmy to provide a clean gconf patch at best tested to integrate well in the beta 5 xulrunner package?
[15:51] <asac> cwong1: the one i got is not proper. i have no idea how it was created, but besides the clutter it appears to be diffed old UPSTREAM vs new master
[15:51] <armin76> asac: and why is it broken?
[15:51] <asac> armin76: it crashes ;)
[15:51] <asac> no time to investigate further, especially because its known to be fixed in git
[15:51] <asac> i am just the messenger ;)
[15:53] <armin76> okay :)
[15:54] <armin76> i guess its fixed in 1.5.20?
[16:00] <asac> armin76: if that is released today then yes, i think so
[16:00] <armin76> it is
[16:01] <asac> we will know later.
[16:01] <asac> afaik it will be uploaded directly
[16:01] <asac> armin76: is it out yet?
[16:02] <armin76> since 5 hours ago
[16:05] <asac> then maybe thats the one broken :)
[16:05] <asac> armin76: ok fix is uploaded
[16:05] <asac> 1.5.20
[18:00] <rzr> hi
[18:01] <rzr> asac: are you waiting after me ? if yes ping me
[18:09] <cwong1> asac: ping
[18:14] <asac> cwong1: pong
[18:15] <asac> cwong1: got my gconf patch request :) ?
[18:15] <cwong1> Got your message and will have Jimmy get you the patch when he comes in.. :)
[18:15] <cwong1> asac: btw, my build falied again
[18:15] <asac> cwong1: he can test it by dropping the patch in debian/patches/ and adding it to debian/patches/series
[18:15] <asac> (in xulrunner-1.9 source)
[18:16] <cwong1> asac: l will let jimmy know
[18:16] <asac> cwong1: failed or just didn't use system-xul?
[18:16]  * asac looks at ppa log
[18:16] <cwong1> asac: it failed to build becuase the build system doesn't have the b5 libxul
[18:16] <asac> cwong1: which build system are you talking about?
[18:17] <cwong1> asac: the ubuntu-mobile ppa
[18:17] <asac> cwong1: hardy?
[18:17] <cwong1> yes
[18:17] <asac> cwong1: the build succeeded
[18:17] <asac>     *  midbrowser_0.3.0b5a-2_amd64.deb  (1.1 MiB)
[18:17] <asac>     * midbrowser_0.3.0b5a-2_i386.deb (1.0 MiB)
[18:17] <asac>     * midbrowser_0.3.0b5a-2_lpia.deb (1.0 MiB)
[18:17] <asac> size looks sane for a xul build
[18:17] <asac> most likely it was dependency wait
[18:17] <cwong1> asac: oh...never midn
[18:18] <asac> cwong1: no problem ;)
[18:18] <cwong1> the built failure was from hppa and sparc
[18:18] <asac> cwong1: let me know if it works as expected (e.g. without gcon)
[18:18] <asac> cwong1: yeah. but i don't think thats build in ppa
[18:18] <asac> cwong1: did someone upload to plain hardy already?
[18:18]  * asac looking
[18:19] <asac> cwong1: are you MOTU?
[18:19] <asac> looks like the upload went to hardy
[18:19] <asac> and you are listed as uploader
[18:19] <asac> strange.
[18:19] <asac> anyway. thanks. its in
[18:20] <cwong1> asac: in the changelog, I specified hardy, is that the right thing to say
[18:23] <cwong1> asac: also the build didnt work. when I run midbrowser, it complains that application.ini file is not found.  If I run it from the /usr/lib/midbrowser directory it works ok.
[18:25] <asac> cwong1: yes the changelog entry is correct
[18:25] <asac> cwong1: is there an application.ini file?
[18:26] <cwong1> asac: yes it is in /usr/lib/midbrowser
[18:26] <asac> ok ... where does the binary live?
[18:27] <cwong1> cwong1: the actual binary lives in /usr/lib/midbrowser
[18:27] <asac> ok
[18:27] <asac> cwong1: whats in bindir?
[18:27] <asac> script or link?
[18:27] <cwong1> asac: but when you enter midbrowser it points to /usr/bin/midborwser and it is a symlink to /usr/lib/midborwser/midbdrowser
[18:28] <asac> hmm
[18:28] <cwong1> do I have to put the application.ini in /usr/bin?
[18:28] <asac> cwong1: no
[18:28] <asac> we don't do that for firefox either
[18:28] <cwong1> or can I specify the MOZILLA_FIVE_HOME somehow to tell it where application.ini is located?
[18:28] <asac> cwong1: so /usr/lib/midborwser/midbdrowser works, but /usr/bin/midbrowser doesn
[18:29] <asac> cwong1: please don't do that. shouldn't be required
[18:29] <cwong1> asac: let me give it a try
[18:31] <cwong1> odd if I enter midbrowser alone it doesn't work but if I typed in /usr/bin/midbrowser or /usr/lib/midbrowser/midbrowser, it works
[18:31] <asac> cwong1: maybe it runs a different midbrowser?
[18:31] <asac> cwong1: try strace -f -eopen midbrowser
[18:32] <cwong1> I did a which midbrowser and it says /usr/bin/midbrowser
[18:32] <asac> to see where it gets its files from
[18:36] <asac> cwong1: http://paste.ubuntu.com/6630/
[18:36] <asac> cwong1: thats from http://www.moblin.org/repos/?p=projects/mobile-browser.git;a=blob;f=toolkit/xre/nsAppRunner.cpp;h=affc067746ad04bc92d3485c1f989950a6b78142;hb=hardy
[18:37] <asac> which implements the XRE_GetBinaryPath function used to determine where to look for applicatoin.ini
[18:37] <asac> maybe you can figure
[18:37] <cwong1> asac: ok thanks
[18:38] <asac> MOZILLA_FIVE_HOME should definitly not be needed
[18:59] <Volans> Hi asac, I have pushed both upstream and ubuntu branches, updated the attached files on the bug and updated the wiki page Firefox3Extensions
[19:04] <asac> Volans: let me look
[19:05] <Volans> ok, I have to go in 10 minutes, I come back after 23 CEST, sorry :)
[19:05] <asac> ok
[19:06] <cwong1> asac: which repo. can I download the xrlrunner1.9~b54-rc2 that matches the one used in the mobile ppa build system?
[19:07] <asac> cwong1: just use the latest hardy
[19:08] <asac> its b5 final
[19:08] <cwong1> ok
[20:31] <fta> asac, is it just me or is gdb no longer loading the dbgsym files ?
[20:53] <Jazzva> asac, about app-install-data ... do we still add Iceweasel/Icedove next to Firefox/Thunderbird
[20:53] <Jazzva> ?
[20:57] <jimmy_> asac: you need another patch for the gconf?
[21:02] <Jazzva> asac, I mean, since there's no dependency on iceweasel in new FF extensions ...
[21:14] <Jazzva> fta, I've noticed thunderbird-3.0 package in your PPA... How's it working? Enough safe to use? :)
[21:14] <fta> i think so, backup your profile just to be on the safe side
[21:14] <Jazzva> Oke ... I'll give it a spin then :)
[21:20] <fta> asac, any progress with the plugins ?
[21:37] <asac> jimmy_: the gconf patch is not usable as it is
[21:37] <asac> it doesn't look like its been done against latest UPSTREAM, but some previous versoin
[21:37] <asac> in short: much too much clean-up work for me to get this in shape
[21:38] <asac> i'd appreciate if i could just drop that in xulrunner/patches and go
[21:38] <asac> fta: dholbach did a backtrace today that looked good. no idea if he used -g though, but he install dbgsym
[21:39] <asac> Jazzva: what do you mean by adding iceweasel next to firefox
[21:40] <jimmy_> where can I get the latest UPSTREAM, and where is xulrunner/patches?
[21:41] <Jazzva> asac: "... extension for Firefox" vs. "... extension for Firefox/Iceweasel"
[21:41] <Jazzva> That's the way it was done before the current release
[21:41] <Jazzva> So, do we still do it that way?
[21:45] <asac> jimmy_: patches/ directory is in the xulrunner-1.9 package
[21:45] <asac> Jazzva: how was that detail displayed?
[21:45] <asac> Jazzva: or was that just unused meta info?
[21:45] <Jazzva> well, Name is displayed as name :), comment is displayed when you click on the extension in the list
[21:46] <Jazzva> No, it was displayed in the list of extensions in gnome-app-install
[21:46] <asac> let me open that dialog
[21:46] <Jazzva> can't remember what GenericName was for... It's just "Firefox/Iceweasel extension" for most of it
[21:46] <Jazzva> *them
[21:46] <asac> ah in the title
[21:46] <asac> yes, i think that can be dropped
[21:47] <asac> change it to Firefox if you touch such an entry
[21:47] <Jazzva> ok
[21:47] <Jazzva> do you want me to change for all of them, or just for new extensions?
[21:47] <Jazzva> (that don't mention iceweasel in the depends)
[21:48] <asac> Jazzva: not sure. top prio is to add new extensions and maybe drop those that are not firefox 3
[21:49] <Jazzva> ok ... i'll add new in the first commit
[21:49] <Jazzva> then drop old in the second
[21:49] <asac> then ... if we still have time we can also cleanup
[21:49] <Jazzva> or, maybe just to say for Firefox 3 vs Firefox 2
[21:49] <asac> Jazzva: point is we should have two dialogs
[21:49] <jimmy_> asac: i downloaded https://launchpad.net/ubuntu/hardy/+source/xulrunner-1.9/1.9~b5+nobinonly-0ubuntu1/+files/xulrunner-1.9_1.9~b5+nobinonly.orig.tar.gz, is this correct?  I don't see a patches directory
[21:50] <asac> Jazzva: can you post an example file
[21:50] <Jazzva> sure thing
[21:50] <asac> jimmy_: apt-get source xulrunner-1.9 in hardy
[21:50] <asac> will give you the complete debian package including the debian/patches directory
[21:50] <Jazzva> http://paste.ubuntu.com/6634/
[21:50] <jimmy_> ok
[21:51] <asac> let me look
[21:51] <Jazzva> ok
[22:07] <asac> Jazzva: ok just add for those support firefox-2 the same mimetype, but with firefox-2 at the end
[22:07] <asac> Jazzva: for those that support firefox 3 we use the old mimetype
[22:07] <asac> using both will make them appear in both dialogs
[22:07] <fta> asac, plugin?
[22:07] <Jazzva> ok
[22:08] <asac> MimeType=application/x-debian-xul-extension-firefox-2
[22:08] <asac> Jazzva: ^^
[22:08] <Jazzva> right :)...
[22:08] <asac> fta: did you manage to see the debug message?
[22:08] <Jazzva> thanks :)
[22:08] <fta> asac, ?
[22:09] <asac> fta:  i asked you to add a printf or break ... remember? you said you want to do that at home ;)
[22:09] <fta> forgot. where was it already
[22:09] <asac> fta: i have no other straw than the backtrace we looked at
[22:09] <asac> so ... if its not that we have to get a backtrace somehow
[22:10] <asac> maybe the reason you never get a backtrace is because of the dbgsym issue you mentioned?
[22:10] <fta> i don't think so.
[22:11] <asac> fta: its in the Gtk plugin window
[22:11] <asac> nsPluginNativeWindowGtk2.cpp
[22:11] <asac> CreateXEmbedWindow
[22:11] <asac> look what value the window field has before it crashes
[22:12] <asac> if its NULL then you have the same crash as the backtrace
[22:12] <asac> and we can try to fix it
[22:19] <asac> fta: can you run with valgrind? maybe there is a memory access error with good line numbers sometime before the crash
[22:27] <fta> asac, it doesn't crash *inside* nsPluginNativeWindowGtk2::CreateXEmbedWindow()
[22:31] <fta> boom, another crash http://paste.ubuntu.com/6635/
[22:31] <fta> during a restart with a saved session
[22:33] <fta> http://paste.ubuntu.com/6636/
[22:34] <asac> !backports
[22:34] <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
[22:36] <asac> fta: i think jazzva saw the nss crash with your archive today
[22:37] <fta> valgrind shows a bunch of Source and destination overlap in memcpy(0xBEA675E8, 0xBEA675E8, 16)
[22:38] <asac> code lines?
[22:39] <fta> http://paste.ubuntu.com/6638/
[22:41] <fta> another bunch of http://paste.ubuntu.com/6639/
[22:41] <fta> http://paste.ubuntu.com/6640/
[22:46] <fta> http://paste.ubuntu.com/6641/
[22:50] <asac> fta: do those happen directly before the flash crash?
[22:50] <fta> it was so slow that i have no idea
[22:51] <fta> the "Invalid read of size 4" occurred a lot so it's not the crasher
[22:51] <asac> everything that doesn't happen right before the crash will make us look at the wrong place
[22:51] <asac> anyway the last looks like the ssl issue
[22:52] <asac> which might be something different
[22:52] <Volans> asac: I'm back :) I have see your reply to the bug, thanks to link the branches, I have forgot to do that
[22:52] <fta> i think i saw a backout in nss today
[23:00] <fta> mozilla bug 427706
[23:00] <ubotu> Mozilla bug 427706 in Libraries "NSS_3_12_RC1 crashes in passwordmgr tests" [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=427706
[23:01] <asac> RC1?
[23:01] <fta> yes
[23:02] <fta> i told you
[23:02] <fta> it's not the same stack... hm
[23:04] <fta> [reed], is there an nss chan on moznet ?
[23:05] <asac> fta: there are basically two developers for nss
[23:05] <[reed]> more than two
[23:05] <[reed]> a lot more than two
[23:05] <asac> yeah ;)
[23:05] <[reed]> Sun and Red Hat
[23:05] <fta> for http://paste.ubuntu.com/6635/
[23:05] <asac> relay, bolyard and kengert
[23:05] <asac> oops
[23:05] <[reed]> http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=mozilla%2Fsecurity%2Fnss&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=month&mindate=&maxdate=&cvsroot=%2Fcvsroot
[23:05] <asac> no idea how to type those ;)
[23:53] <fta> Jazzva, if you see another crash nss related, please capture a trace, bt + bt f
[23:53] <Jazzva> hmm ... ok, though I switched back to hardy version
[23:53] <fta> oh
[23:54] <fta> nm then
[23:54] <Jazzva> it happened mostly when I entered a username and a password, saved it, then changed it
[23:54] <Jazzva> or when I saved another username on the same page
[23:54] <fta> oh, then it was probably mozilla bug 427706
[23:54] <Jazzva> when it would start to crash it wouldn't open the "Saved passwords" window in Preferences
[23:54] <ubotu> Mozilla bug 427706 in Libraries "NSS_3_12_RC1 crashes in passwordmgr tests" [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=427706
[23:55] <fta> this is fixed now. I've pushed a new nss
[23:55] <Jazzva> yep
[23:55] <Jazzva> that's the one
[23:55] <Jazzva> something similar
[23:55] <Jazzva> *** glibc detected *** ../../../../dist/bin/xpcshell: free(): invalid pointer:
[23:55] <Jazzva> 0x0aa43b24 ***
[23:56] <Jazzva> Good to hear it is fixed :)
[23:58] <fta> [reed], from http://paste.ubuntu.com/6635/  what symbol should I report the crash from ?