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