[04:56] <[reed]> micahg: have you all not been getting complaints about mozilla bug 521495 ?
[04:56] <[reed]> I would expect that to be a major issue
[04:56] <micahg> [reed]: just one AFAIK
[12:07] <asac> bug 49079
[12:07] <asac> bug 490792
[12:30] <asac> fta: was the asm fix committed?
[12:30] <asac> wasnt sure from the mails i got last night
[12:30] <asac> chromium that is
[12:31] <asac> bug 488354
[18:50] <fta> asac: yes, should be in today's tarball
[18:51] <fta> i had to pull some strings, and they'll try to auto-generate that file at build time, but for now, the fix is back
[19:22] <[reed]> asac: I assume you'll upstream those patches?
[19:34] <asac> [reed]: ?
[19:34] <asac> arm patches?
[19:34] <asac> yes
[19:34] <asac> feel free to take them and forward etc.
[19:34] <asac> :)
[19:36] <[reed]> mozilla bug 530087 seems to have some stuff
[19:37] <[reed]> though, I'd recommend separate patches
[19:37] <[reed]> bugs*
[19:37] <asac> bug 530087
[19:37] <asac> oh
[19:37] <asac> moz bug
[19:37] <asac> on a call
[20:02] <asac> [reed]: would be nice if someone would post _why_ things get backed out
[20:02] <[reed]> I agree
[20:02] <[reed]> in general, people do
[20:02] <asac> now we dont know what the status is ;)
[20:03] <asac> let me take a break and then see whats up with the arm bugs filed by dmart
[20:07] <asac> backing out bug 530087 due to talos segfault on maemo
[20:10] <asac> bug 530087
[20:11] <asac> bug 488354
[20:11] <asac> bug 490792
[20:15] <asac> [reed]: first bug of those has a patch for thumb2 support ... second one probably suggests cherry picking the fix landed on 1.9.2 to 1.9.1
[20:15] <asac> not sure what about the bug you mentioned
[20:15] <[reed]> the patch for the bug I mentioned includes something similar to the thumb2 support patch
[20:16] <[reed]> if you look at the patch carefully
[20:16] <[reed]> :)
[20:16] <asac> oh
[20:16] <asac> [reed]: so yeah. maybe thats the reason for the crashes
[20:16] <asac> too new instructions they should be guarded by __thumb__
[20:16] <asac> like the one posted in the first bug
[20:16] <[reed]> yeah
[20:30] <asac> fta: so positive about copying todays chromium to native PPA?
[20:30] <asac> e.g. patch is in et al?
[20:51] <fta> asac, let me check
[20:54] <fta> asac,         .section .note.GNU-stack,"",%progbits
[20:57] <asac> thx
[20:57] <asac> fta: do i need and depends etc. too?
[20:57] <asac> or just karmic/lucid is good enough to build it?
[21:02] <fta> asac, er, what do you mean?
[21:04] <asac> fta: https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.3/+build/1374871
[21:05] <asac> fta: i mean: do we need any build deps not in the archive?
[21:05] <asac> maybe deting the other packages from the ppa would avoid that in futzure ;)
[21:05] <asac> python- ... ia32-
[21:07] <fta> no, nothing
[21:13] <bdrung> asac: is there an reason for m-d to extract the xpi file into a special directory and copy it then to it's target directory?
[21:18] <asac> bdrung: best i can think of is that unzip behaves rogue if you just unzip it to an existing tree
[21:18] <asac> i remember there were issues
[21:18] <asac> but cant tell what
[21:28] <micahg> asac: you saw firefox 3.5.6 build 1 was tagged, right?
[21:32] <asac> i thought build2 was approaching
[21:35] <[reed]> and possibly build3
[21:36] <micahg> ah, you guys have better intel than I do :), I just watch the tags
[21:42] <asac> i need to get this all-in-one-package-wonder thing going ;)
[21:43] <asac> actually i think i should just commit it.
[21:43] <asac> it worked reasonably well
[21:43] <asac> only things missing was making it more adept on handling the "still use xulrunner and system libs" case
[21:46] <micahg> asac: is this for lucid or for everything?
[21:47] <asac> first lucid ... then the rest
[21:52] <bdrung> asac: do you know which packages were affected? i would like to merge both steps to one. adding some switches to unzip can resolve the problems.
[21:55] <asac> bdrung: i have no idea. if it works well, then go for it :)
[21:55] <asac> one point is that we usually have to clear all the upstream files first ... but that sounds unrelated
[21:58] <bdrung> asac: we can remove them later, too.
[22:00] <bdrung> asac: we use unzip -o (o for overwrite) to avoid interaction.
[22:00] <bdrung> this was maybe the reason for trouble
[22:02] <bdrung> asac: do you know how to find executable files (and no, not by checking the exec bit)?
[22:02] <asac> hmm i think we figured the -o
[22:02] <asac> anyway
[22:02] <asac> go ahead ;) ... if there are regressions we know where to find you
[22:03] <bdrung> yes ;)
[22:15] <fta> dtchen, is the p-a that makes flash a cpu pig?
[22:38] <micahg> asac: http://feeds.arstechnica.com/~r/arstechnica/index/~3/IMqEchfv4-U/commonjs-effort-sets-javascript-on-path-for-world-domination.ars
[22:44] <asac> yeah. they probably dont see the obvious: there is no js engine ;)
[22:44] <asac> at least none that can be supported ;)
[22:50] <fta> v8
[22:53] <micahg> I can't imagine the security nightmares if js becomes mainstream on the desktop
[23:06] <dtchen> fta: I don't understand your question
[23:10] <fta> dtchen, in ff and chromium, when i visit some sites with flash, my cpu gains ~25% to 50% and never goes down.
[23:10] <fta> dtchen, with chromium, it's easy to see it's the flash plugin, because it has its own process
[23:11] <fta> but not everyone is seeing that, so it looks like my sdl issue
[23:17] <dtchen> if an app requests very low latency, PA is happy to grant that, and cpu usage will skyrocket
[23:20] <dtchen> does chromium have a native pulse backend yet?
[23:21] <fta> hm, not sure
[23:40] <fta> asac, http://code.google.com/p/chromium/issues/detail?id=29118
[23:55] <fta> dtchen, alsa only
[23:55] <dtchen> boo