=== m_conley is now known as m_conley_away === m_conley_away is now known as m_conley === m_conley is now known as m_conley_away === m_conley_away is now known as m_conley [17:27] and backporting is about to become a nightmare: http://downloadsquad.switched.com/2011/02/07/firefox-4-5-6-and-7-to-be-released-before-the-end-of-2011/ [17:28] aside from the lack of a concurrent firefox-next branch, this is literally out of nowhere. [17:51] LLStarks, that is exactly why we don't want extensions in the archive ;) [17:52] be gone with the lot of them! [17:53] even a best-in-class add-on like abp is just another thing we'd need to worry about [17:53] well, that's gone already ;) [18:01] * micahg is conflicted http://is.gd/W7AqLB [18:06] 4.0 needs to come out first [18:08] micahg, yeah ;) [18:09] we need to speed up efforts to get xulrunner out of main [18:09] i don't want natty to release with it still in main ;) [18:09] chrisccoulson: yep, what's left, couchdb? [18:09] micahg - couchdb, swt-gtk and icedtea-plugin [18:10] icedtea-plugin is easy to resolve, we just build it against a firefox SDK [18:10] * micahg doesn't think couch should be in main [18:10] it's a disaster [18:10] heh [18:10] for couchdb though, we can provide a separate libmozjs, decoupled from firefox releases [18:10] for swt-gtk, i've got no idea what to do [18:11] chrisccoulson: can't we just ship a copy of the xul headers in icedtea-plugin or will that break later? [18:11] i can't find anybody who cares about swt-gtk, yet the only thing keeping it in main is a server package [18:11] micahg - icedtea uses xpcom, so it needs a full SDK to build against [18:11] but it should be building against firefox anyway [18:12] chrisccoulson: indeed, ok, I'll have to continue this later [18:12] i'm tempted to kill the browser part of swt-gtk entirely, and just drop tuxguitar, vuze etc [18:13] is eclipse using it too? [18:13] chrisccoulson: yeah, but that's switching to webkit mostly for 3.7 [18:13] I might be able to get it ported to webkit for 3.6, but it still uses xul as a fallback [18:49] m_conley, did you resolve your virtualbox issue yet? [18:49] you can probably start the old kernel until it's resolved [18:49] chrisccoulson: hey - I've gotten absorbed in another issue. I was just going to wait for the fix to manifest in the packages. [18:50] chrisccoulson: I'm checking out Thunderbird integration with the Messaging Menu. Some good work has been done there - just needs to be ported to C++ [18:50] m_conley, oh, are you looking at the extension that exists already? [18:50] chrisccoulson: yep [18:50] yeah, i think we pretty much need to rewrite that (from the last time i looked) :/ [18:51] chrisccoulson: and it works alright - but it'll need quite a bit of love to massage it into core. [18:51] m_conley, how do people feel about me shipping globalmenu-extension by default with thunderbird? [18:52] do you think it's ready? i'd like to get people testing it soon ;) [18:52] chrisccoulson: Good question - lets ask in #maildev and see what davida thinks [18:52] chrisccoulson: does it do anything if unity isn't installed? [18:52] or running [18:52] i'm here [18:53] hi davida_, how are you? [18:53] davida_: oh, hey - chrisccoulson was wondering if he might start shipping globalmenu-extension by default with Thunderbird to help with testing. [18:53] micahg - it's inert if unity isn't running (it falls back to its own menus) [18:53] are we talking about the default ubuntu distro, or the mozilla build? [18:54] davida_, it would just be with the ubuntu build [18:54] I think just the Ubuntu distro - correct, chrisccoulson? [18:54] yeah, that's right [18:54] (for now, right? assuming it's good, we'd want that upstreamed, right?) [18:55] davida_: correct - I think this is just to get it to a wider audience, to find/iron out any big bugs. [18:55] and then I think we'll start migrating to core. [18:55] davida_, yeah, the plan is to work on getting it in to core, but it's timed badly with the firefox release schedule [18:55] in general, I'm fine with it, assuming the experience is likely to be much better. [18:56] oh, you're asking me about TB only, though, right? [18:56] davida_: correct. [18:56] davida_, yeah, just tbird for now [18:57] sorry, another stupid q- how would this end up being deployed, as a security/almost-automatic update? [18:58] have you run it through whatever beta/testing scenarios you usually use? [18:58] davida_, it would only be deployed to our development release at the moment [18:58] so, people running it are all alpha testers anyway. it's not the sort of thing we'd deploy as a stable update [18:58] no objection, then, definitely not, at least from me. [18:59] excellent, thanks [18:59] it might be good to get clarkbw or andreasn1 to look at it from the UI/UX POV, if they haven't already [18:59] dpm, still here? [19:00] davida_: ok, noted. I'll get in touch. [19:00] dpm, looking at bug 710591, i wonder if what i'm doing right now would be useful once this is fixed [19:00] Launchpad bug 710591 in launchpad "Ubuntu upstream translation imports overwrite Ubuntu translations" [Critical,In progress] https://launchpad.net/bugs/710591 [19:01] m_conley, davida_ - thanks [19:01] chrisccoulson: np, i'm happy to see this thing moving along! [19:03] ditto. davida_: there's also been good work done on Messaging Menu integration: https://addons.mozilla.org/en-US/thunderbird/addon/indicators-for-thunderb-223374/ [19:04] davida_: as a demo, it's quite nice. The code needs some re-writing to prepare it for core, though. Still - the functionality is nice. When this is done, the UI is going to be pretty slick. [19:04] sweet [19:07] hey fta, I'm not sure. I've been talking to henninge and they are planning to have a fix for it in the LP rollout this week. I think we'll have to check out whether the behaviour is the expected then [19:10] dpm, i guess the hours i've spent fighting this bug are a pure loss then [19:12] dpm, the merge proposed by danilos can't work as it's impossible to set a string to its upstream value once it diverged in lp [19:12] dpm, but i discovered that after writing all the code :P [19:13] fta, :( afaik (at least for Ubuntu it was like this before the bug), you can set a string to its upstream value by selecting the upstream value. Once you've done that, that message "tracks" upstream [19:14] but chromium is slightly different, as there is no Ubuntu package open for translation [19:14] dpm, not my fault, it's a launchpad limitation [19:15] I'm not saying it's anyone's fault, just describing the situation [19:15] I wished other packages had translations as well maintained as chromium [19:27] dpm, i guess i can drop some restrictions in my code once lp is able to feed me the proper strings. For now, if lp gives me a translation which is the same as the one i get from upstream, i reject it if i received another version in the past (from lp) [19:28] dpm, the reason i had to do that is that translations don't stick, lp keeps overwriting them with the upstream ones. i tried to re-inject them twice, they don't stick for more than 1 day [21:11] err, Firefox, xulrunner, and Thunderbird get delayed but Seamonkey still tomorrow [21:11] yay [21:13] oh ? interesting [21:13] i think they're all ready to go though aren't they? [21:13] chrisccoulson: 1.9.1 will go out tomorrow [21:13] 1.9.2 is being respun [21:14] oh? that's not what i wanted to hear ;) [21:14] oh, yes [21:14] just seen now [21:14] so, it means I still have to rush to test Seamonkey tonight :) [21:15] that sucks. that's my evening planned then ;) [21:15] chrisccoulson: you could do it in the morning ;) === m_conley is now known as m_conley_away