[07:00] <Omega> We get to keep Firefox in Oneiric :) https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-default-browser
[07:02] <micahg> Omega: that's the idea :)
[07:04] <fta2> this blueprint is b*t
[07:05] <fta2> no modern browser has an engine stable for 6 months.
[07:06] <micahg> fta2: the premise was we don't necessarily need a "modern browser" as the default
[07:06] <fta2> if one doesn't get an update in 6 months, it's sure full of vulnerability, no one should ever want to have that installed
[07:06] <fta2> -ty+ties
[07:06] <micahg> fta2: no, the idea was to use webkit which we plan to do stable branch releases for as the backend so security isn't a concern
[07:07] <fta2> ok, so it's definitely a good time for me to find another distro then
[07:07] <micahg> fta2: don't worry, I cancelled the session
[07:08] <fta2> "security isn't a concern" is not my definition of a good distro
[07:08] <micahg> fta2: huh?  it's most definitely a concern, I said it wasn't a concern because I'll be backporting security patches from webkit trunk to the stable releases, not that it would be ignored
[07:10] <micahg> sorry for not being more clear, It's 1 AM here
[07:11] <fta2> http://ubuntuforums.org/showthread.php?p=10746888#post10746888  :(
[07:12] <micahg> fta2: well, we would need to know what toolchain/compile flags google uses to do some type of real world comparison
[07:17] <micahg> fta2: maybe check with upstream if they have any tricks you can use in your packages
[07:18] <fta2> they don't, everything is in the gyp files
[07:18] <fta2> but our toolchain sucks more and more release after release
[07:18] <micahg> fta2: also, is it a specific release that's slower?
[07:19] <micahg> if we can pinpoint the regressions, we can try to get them fixed
[07:19]  * micahg is hoping 4.6 to be good
[07:19] <micahg> *gcc-4.6
[07:19] <micahg> I'm noticing better performance from chromium as the releases progress
[07:19] <fta2> why would it? we hardern more and more stuff, making the whole desktop slower
[07:20] <fta2> it = gcc 4.6
[07:20] <fta2> natty is way slower than maverick here
[07:20] <fta2> itself slower than lucid
[07:20] <fta2> etc
[07:20] <micahg> well, the optimizations the compiler does with each release gets better as well, so hopefully that balances out
[07:21] <fta2> obviously not
[07:21] <micahg> desktop performance is the focus of one of the sessions at UDS
[07:22] <micahg> phoronix also posted some stats on speed regressions, I think this will be a focus for oneiric and the LTS
[07:23] <micahg> fta2: if you find we need something to make chromium faster, let me know and I"ll see what I can do
[07:25] <fta2> it's easy to test. grab the same version built with different toolchains and test. the 4 ppas are good candidates. exact same packaging
[07:28] <chrisccoulson> fta2 - regarding the default-browser blueprint, see my responses to the discussion on the ubuntu-desktop list ;)
[07:29] <chrisccoulson> micahg - have you tried dissecting the chrome binary btw (with objdump and readelf). you might be able to have a guess at some of the major compiler and link flags from doing that
[07:30] <micahg> chrisccoulson: nope
[07:31] <chrisccoulson> is chromium built with -pie?
[07:32]  * micahg forgot if we reenabled, checking
[07:33] <chrisccoulson> i'm guessing chromium is pie, and chrome isn't
[07:34] <chrisccoulson> woah
[07:34] <chrisccoulson> chrome: Relocation section '.rela.dyn' at offset 0x2f680 contains 318 entries:
[07:34] <chrisccoulson> chromium: Relocation section '.rela.dyn' at offset 0x1db60 contains 214625 entries:
[07:34] <micahg> yep, with -pie
[07:34] <chrisccoulson> there is something fundamentally different with how we build chromium.
[07:34] <micahg> except on ARM I think
[07:34] <chrisccoulson> yeah, pie is a big killer there
[07:35] <chrisccoulson> the difference in the amount of relocations is pretty awful
[07:35] <chrisccoulson> that's not just a minor toolchain quirk ;)
[07:35] <micahg> well, unless we can make PIE more efficient, there's not much we can do about that
[07:35] <chrisccoulson> there isn't a way to make PIE efficient. it's a performance killer by design
[07:36] <chrisccoulson> every access to a global variable goes via the GOT
[07:36] <chrisccoulson> and every function call via the PLT
[07:36] <chrisccoulson> which is pretty wasteful
[07:37] <chrisccoulson> comparing the binaries could turn in to an interesting little experiment
[07:38] <micahg> chrisccoulson: well, the tradeoff would be to link to more libs instead of having one huge binary, another speed killer
[07:41] <chrisccoulson> well, one huge binary is actually a performance benefit when you're not using -pie
[07:41] <chrisccoulson> with -pie, it doesn't make much difference
[07:41] <chrisccoulson> this is why mozilla ships fennec as one big binary on android :)
[07:42] <chrisccoulson> when you're linking against external libs, the number of relocations the linker needs to do increases, and that isn't cheap
[07:42] <chrisccoulson> but in the -pie case, that doesn't really matter, because you already do all those relocations
[07:44] <chrisccoulson> i'd be interested to see a chromium build without -pie, just to see the difference :)
[07:45] <micahg> chrisccoulson: I can kick one off locally tomorrow, I need to finish thunderbird now
[07:45] <chrisccoulson> that's ok, i can do it here later
[07:46] <chrisccoulson> we also use BIND_NOW in ubuntu, which is a startup time killer
[07:46] <chrisccoulson> especially with apps that have a lot of relocations (like firefox and chromium) :)
[07:47] <chrisccoulson> which is probably one reason why upstream mozilla builds start significantly faster than our builds ;)
[07:50] <micahg> chrisccoulson: could we build with static libs and optimize at build time so it can all be loaded quickly (PGO?)
[07:50] <chrisccoulson> it's not going to make much of a difference with -pie ;)
[07:50] <chrisccoulson> and PGO doesn't really improve loading speed
[07:50] <micahg> chrisccoulson: would help with start time though, wouldn't it?
[07:51] <chrisccoulson> well, when I tried PGO here, it didn't really change startup time
[07:51] <micahg> hmm, that could be because we have PIE enabled w/dynamic libs + BIND_NOW like you said
[08:06] <fta2> chrisccoulson, i tried ff4 on android, it's way slower than the stock browser. start time is at least 10 times slower on my tablet
[08:10] <fta2> chrisccoulson, and btw, i really don't think pie does any good to chromium. there's already the sandbox
[08:11] <fta2> btw, i do a static build, like upstream, hence the huge binary
[08:11] <fta2> the only difference is PIE, maybe ld-gold (not sure)
[08:12] <fta2> and of course, they use an older toolchain (used to be hardy)
[08:22] <chrisccoulson> fta2 - yeah, ff4 on android isn't fast
[09:26] <xjjk> hello, somewhat OT
[09:26] <xjjk> is there a PPA containing only Firefox Aurora builds?
[09:26] <xjjk> instead of nightlies
[09:58] <chrisccoulson> xjjk, no. in any case, they're pretty much nightly anyway, aren't they?
[10:44] <chrisccoulson> chromium (no -pie) - Relocation section '.rela.dyn' at offset 0x1d0c0 contains 412 entries (versus 214625 for -pie)
[10:45] <chrisccoulson> ouch ;)
[14:10] <chrisccoulson> bug 776355 - wtf?
[14:11] <ubot2> Launchpad bug 776355 in firefox "commercial image in background of firefox 3.6.17" [Undecided,New] https://launchpad.net/bugs/776355
[15:57] <chrisccoulson> ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
[15:58] <chrisccoulson> asac - the patch we carry for mozilla bug 467766 is causing mozilla bug 654099 :(
[15:58] <ubot2> Mozilla bug 467766 in Preferences: Backend "user settings for pref keys with defaults in extension get reset on upgrade" [Normal,Assigned: ] http://bugzilla.mozilla.org/show_bug.cgi?id=467766
[15:58] <ubot2> Mozilla bug 654099 in Firefox Sync: Backend "intl.accept_languages is being set to non-localized value chrome://global/locale/intl.properties" [Normal,New: ] http://bugzilla.mozilla.org/show_bug.cgi?id=654099
[16:50] <xjjk> chrisccoulson: I didn't think so? thought they were better-tested nightlies
[17:09] <micahg> chrisccoulson: I thought that first one was mostly fixed for 4.0, maybe we can just drop it?
[17:10] <chrisccoulson> micahg - i'm not sure, i don't think anything has changed there
[17:10] <micahg> chrisccoulson: re commercial image bug> I asked for a screenshot
[17:11] <micahg> chrisccoulson: I remember having to fuzz that patch at one point, also, when you did the 4.0 upgrade, you fuzzed it as well
[17:12] <micahg> so, the logic changed a bit, but idk if it was actually fixed
[17:15] <chrisccoulson> no, i doubt it's fixed it, as it's a fundamental issue with the way it works (and a long term fix would probably go elsewhere too)
[17:32] <jcastro> fta: ok so that download progress thing looks niiiiiiiiiice.
[17:32] <jcastro> chrisccoulson: you're behind now!
[17:32] <chrisccoulson> jcastro - http://people.canonical.com/~chrisccoulson/unityfox.png ?
[17:33] <chrisccoulson> and see my post to the ayatana list too ;)
[17:33] <jcastro> yeah!
[17:34] <fta> jcastro, indeed
[17:39] <chrisccoulson> jcastro, https://lists.launchpad.net/ayatana/msg05617.html
[17:39] <chrisccoulson> basically, i need some design input really ;)
[17:40] <jcastro> yeah
[17:40] <chrisccoulson> and mpt suggested last week that the way we indicate progress on the launcher could be improved
[17:40] <jcastro> I think 2 is correct, download only
[17:40] <jcastro> and for 3, just wiggle at the end
[17:40] <jcastro> that makes the icon shake out a bit to indicate that you're done and turns the home button blue
[17:40] <chrisccoulson> yeah, i agree. i'm just not sure it's clear what the progressbar represents from a browser :)
[17:41] <jcastro> yeah
[17:43] <fta> jcastro, did you have a chance to check my bug from yesterday?
[17:46] <jcastro> I have not
[17:46] <jcastro> I have been slammed with UDS planning
[17:46] <jcastro> I haven't even been able to check the appmenu bug with trevino
[18:22] <fta> ok
[18:29] <micahg> chrisccoulson: about the mozilla patches, I was originally thinking about dropping the prefs patch, but is that a valid tradeoff to drop prefs in favor of have the default language correct?
[18:29] <chrisccoulson> micahg - yeah. the prefs issues is an edge-case
[18:29] <chrisccoulson> the language issue makes it pretty much unusable, and for no obvious reason :/
[18:30] <micahg> chrisccoulson: k, go ahead and drop it then
[18:30] <chrisccoulson> it happened to me too, and all google sites become unusable (i can't understand cherokee)
[18:30] <micahg> chrisccoulson: since it's not a regression over release, I can't push through -security, but we could SRU it
[18:30] <chrisccoulson> and you need to be about to understand cherokee to change your language back to english in google ;)
[18:30] <micahg> chrisccoulson: there's a link to use google in english ;)
[18:30] <chrisccoulson> micahg, that's ok, i've got another change to do a SRU for too
[18:31] <chrisccoulson> micahg, is there? i didn't notice that
[18:31] <chrisccoulson> all i got was an unusable page :)
[18:32] <chrisccoulson> micahg - we can try to figure out a better way to fix it, but it would likely involve a more intrusive patch
[18:32] <micahg> chrisccoulson: I'll add a google search page to QRT so we can catch it in the future
[18:32] <chrisccoulson> in any case, the current patch breaks a public mozilla API, so we really shouldn't have it in the first place ;)
[18:33] <chrisccoulson> micahg, https://launchpadlibrarian.net/69336194/googlehome.png ;)
[18:33] <chrisccoulson> actually, this one is more valid: https://launchpadlibrarian.net/69336109/searchresult.png
[18:33] <chrisccoulson> the first screenshot is just someone manually using cherokee
[18:33] <chrisccoulson> the second one is a result of the bug
[18:34] <micahg> weird, I got a link for english on mine
[18:35] <chrisccoulson> 1 second, i will try and see if i can get google to automatically pick the wrong language again
[18:36] <chrisccoulson> micahg, hmm, there's no link to use english here :/
[18:36] <micahg> chrisccoulson: k
[18:37] <chrisccoulson> so, i definitely think we should regress the other bug to fix this one
[18:37] <chrisccoulson> it sucks, but i think this one is worse
[18:43] <micahg> chrisccoulson: it would be nice if we have a better fix before we push to lucid/maverick
[19:09] <Omega> chrisccoulson: Do you want me to ask the firefox ux people what they think of unityfox?
[19:10] <chrisccoulson> Omega, do you know them?
[19:10] <Omega> yes
[19:10] <chrisccoulson> well, i'd certainly like to know what their thoughts are for download progress indication in general
[19:10] <chrisccoulson> i don't like the current download progress window ;)
[19:11] <chrisccoulson> but i don't think integrating it with the unity launcher is a substitute for that
[19:11] <chrisccoulson> which is why i'm stuck ;)
[19:11] <Omega> Alright, I'll mention it on IRC, if it sparks some interest I'll post it on the mailing list :)
[19:11] <chrisccoulson> thanks
[19:18] <fta> http://www.netmarketshare.com/browser-market-share.aspx?qprid=1
[19:18] <Omega> chrisccoulson: Do separate firefox windows use separate download lists?
[19:19] <chrisccoulson> Omega, no
[19:19] <kbrosnan> on non-untiy firefox, no
[19:21] <Omega> chrisccoulson: What is the multiple firefox problem?
[19:22] <Omega> (Err, I mean, I don't see how having multiple instances of firefox open complicates the matter)
[19:22] <chrisccoulson> Omega, in unity, all firefox windows are represented by a single icon on the launcher
[19:23] <chrisccoulson> the multiple windows case is not a problem, as there is only one process talking to the launcher
[19:23] <chrisccoulson> but, if you run multiple instances of firefox, then you can have several processes all trying to control progress indicators on the launcher
[19:23] <chrisccoulson> i guess that's a design flaw in unity though ;)
[19:26] <chrisccoulson> niiiiice, i just tried the chromium implementation too :)
[19:29] <Omega> chrisccoulson: Ah, yes, that does seem like a design flaw.
[19:29] <Omega> You should raise that issue on the mailing list.
[19:31] <chrisccoulson> Omega, which mailing list?
[19:31] <chrisccoulson> i'll probably just grab the guy working on launcher design at UDS :)
[19:32] <Omega> ayatana would probably be the most appropriate
[19:32] <Omega> Because it needs design thought.
[19:33] <Omega> They can take it into different directions, maybe spawning more icons when different processes want to use the launcher, or having multiple progress indications
[19:38] <Omega> chrisccoulson: Are you at UDS?
[19:38] <chrisccoulson> Omega, i will be, from sunday night
[19:41] <Omega> Fun :)
[19:43] <chrisccoulson> yeah, i'm looking forward to it ;)
[19:44] <chrisccoulson> although, it's always a busy week
[19:44] <chrisccoulson> and we've got lots of things to figure out, like, how we support firefox in the distro ;)
[19:49] <m_conley> chrisccoulson: i've been thinking about that - the behaviour should be the same as Chromium, no?
[19:49] <chrisccoulson> m_conley, in general, or just for the launcher bits?
[19:50] <m_conley> chrisccoulson: hm - maybe I didn't read enough scrollback.  I just assumed you were talking about how you were going to deal with the new release cycle
[19:50] <m_conley> chrisccoulson: if that's not the case, ignore me. ;)
[19:50] <chrisccoulson> m_conley, oh, i misunderstood entirely there
[19:50] <chrisccoulson> different conversation ;)
[19:50] <chrisccoulson> lol
[19:50] <chrisccoulson> yes, it should be mostly the same i guess
[19:52] <chrisccoulson> m_conley, our main bottleneck is going to be because of how we distribute translations
[19:52] <chrisccoulson> because we bundle them with our language packs, which are built using an export from launchpad
[19:52] <m_conley> I see (I think)
[19:53] <chrisccoulson> and we don't want the security team being stuck testing 10s of new language packs for 100s of applications every few weeks ;)
[19:54] <chrisccoulson> and i still have no idea how long firefox 4 is going to be supported :/
[19:54] <chrisccoulson> i'd like to upgrade all our users to it, but i don't want to do it before i know we're fully prepared for dealing with faster releases
[19:54]  * m_conley nods
[19:55] <chrisccoulson> but if firefox 4 is supported for another 6 months or so, then that gives us plenty of time
[19:55] <chrisccoulson> if it's only until firefox 5 is released, then we'd be screwed ;)
[19:56] <m_conley> chrisccoulson: just checked - it's 6 months after FF5 is released.  Minimum.
[19:57] <micahg> m_conley: is that info public somewhere, I've trying to find timetables for weeks
[19:57] <m_conley> micahg: I literally just walked over to some Firefox people and asked.  I have no idea if it's on a wiki anywhere.  It probably should be.  :/
[19:58]  * micahg feels bad dropping conkeror now :(
[19:58] <chrisccoulson> micahg, i wouldn't worry. we'd kill it anyway ;)
[19:58] <chrisccoulson> we shouldn't be spending time on things like that really
[19:59] <micahg> well, I'd like to see if we come up with a xul plan at UDS or not
[19:59] <chrisccoulson> drop it and stick it in a PPA ;)
[19:59] <chrisccoulson> tbh, there's not much left in the archive using it now
[20:01] <chrisccoulson> http://paste.ubuntu.com/602927/
[20:01] <chrisccoulson> and conkeror is already gone
[20:01] <chrisccoulson> python-gtkmozembed is going anyway
[20:02] <chrisccoulson> chmsee has a patch for a webkit port somewhere. it needs it anyway, as it uses gtkmozembed
[20:02] <chrisccoulson> google-gadgets has gone already
[20:02] <micahg> fennec will move to internal xul I think
[20:02] <chrisccoulson> why are these all still in my apt cache?
[20:02] <chrisccoulson> these went weeks ago :)
[20:02] <chrisccoulson> dehydra only uses spidermonkey
[20:03] <micahg> chrisccoulson: I still have a few universe packages to port to mozjs
[20:03] <chrisccoulson> that only really leaves instantbird, mozplugger and xiphos
[20:04]  * micahg thought xiphos was being ported to webkit
[20:04] <chrisccoulson> i'm not sure
[20:05] <chrisccoulson> that's not the sort of application i use regularly ;)
[20:05] <micahg> I'll talk to the instantbird devs, might want to switch that to internal xul as well
[20:05] <micahg> or kill
[20:05] <chrisccoulson> yeah, i'm not too fussed about that
[20:48] <chrisccoulson_> ok, firefox uploaded to natty-proposed
[20:50] <BUGabundo> evening
[20:54] <micahg> chrisccoulson_: heh, that's not something we do often :)
[22:34] <Omega> chrisccoulson_: They say it covers the most iconic part of the logo.
[22:36] <Omega> chrisccoulson_: this is what she said:
 Tim: it and the notification number cover the most iconic parts of the logo,
 as a simple progress indicator it's not bad.  i'd just change it if i were designing it with only firefox logo in mind :)
[22:37] <Omega> chrisccoulson_: maybe this is a good thing to mention to mpt, a possible alternative would be to place the progress bar on top of the icon (kind of like how firefox indicates page load progress)
[23:56] <ripps> huh... chromium from the dev ppa keeps freezing 10 seconds after it starts. I even tried starting it in incognito in case an extension was causing it, but no difference.
[23:57] <ripps> it's barely using any cpu too, it just stops doing anything
[23:57] <ripps> I have to kill it using xkill