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