[00:00] yep === fta_ is now known as fta [00:00] nspr_flags_by_pkg_config_hack [00:00] is there an upstream bug, or a better explanation of what that's trying to fix? [00:03] mconnor, it is needed because our tarball for firefox 3.0 is not full, it doesn't have nspr sources [00:03] you guys and your wacky tarball [00:06] mconnor, the goal is to have less bits to upload, it's 10M vs 40M for the full one [00:06] what all do you take out? [00:07] that seems like you're tossing a lot of code out of the tarball [00:07] hold on [00:07] I wish you could just point at the mozilla tarball + your patches... seems like it'd be saner than anything [00:08] oh, yeah, are you guys pulling the know your rights patch in 3.0.5? [00:11] http://bazaar.launchpad.net/~mozillateam/mozilla-devscripts/mozilla-devscripts/annotate/head:/src/mozclient/patches/xulbrowser_target.patch [00:12] i guess, with 3.0.5, our know-your-rights patch will conflict so it will probably go away [00:12] oh, right, because you build the app package separate from the xulrunner package [00:12] it'll definitely conflict :) [00:14] hmm [00:15] the don't depend on NSPR sources, couldn't you copy that file from the nspr location when building the source tarball? [00:16] I'm mildly worried about us making changes to the original that you don't pick up [00:17] everything is possible [00:17] yeah [00:17] I know [00:18] I'm just treating this like I treat code reviews [00:18] if there's a potential for stuff to go wrong, it will almost certainly go wrong [00:18] the point here is that when system nspr is requested, configure should not depend on the in-source version of nspr-config, even if it's in the tree, it may have diverged from the real system libs/headers [00:34] fta: the patch means that configure depends on a specific version of make-system-wrappers.pl from the time of patch creation [00:34] I'm not sure how that's better [00:44] mmm [00:56] fta: what are the jemalloc patches doing? [00:58] are they still applied ? [01:00] oh, I missed that they're commented out of the series patch [01:00] ok! [01:00] s/series patch/series file/ [01:01] i should clean that up [01:01] bz436133_att322801.patch should be replaced with the patch that landed on 3.1 :P [01:58] man, this default prefs patch is weird [05:52] uh. [05:55] fta / asac : I am confused by how/if part of one of these patches works... [05:57] oh, nm [05:57] man I hate this code [09:57] mconnor: ok i am back from leave. [09:59] mconnor: have to catch up on mail and stuff and then will focus on getting the patches upstreamed to bugs === fta_ is now known as fta [10:51] fta: wanna take a look at one or two extensions from gnomefreak ;) [10:51] i think he asked for a merge of firegpg [10:51] and has two more new packages in pipeline [14:38] @time [14:38] Current time in Etc/UTC: November 24 2008, 14:38:22 - Next meeting: Server Team in 1 day [14:39] @time central [14:39] Current time in Canada/Central: November 24 2008, 08:39:01 - Next meeting: Server Team in 1 day [14:39] @time US/central [14:39] Current time in US/Central: November 24 2008, 08:39:08 - Next meeting: Server Team in 1 day [14:59] @time [14:59] Current time in Etc/UTC: November 24 2008, 14:59:21 - Next meeting: Server Team in 1 day [16:20] asac: http://people.mozilla.com/~mconnor/trademark-review/Ubuntu/Round%201/ [16:21] asac: the "3.0 only" are stuff we have or should upstream [16:21] the "Needs Discssion" we should talk about :) [16:42] <[reed]> mconnor: #16 is wrong on your list [16:42] <[reed]> the prefs are in Firefox's prefs upstream [16:43] <[reed]> not in Toolkit's [16:43] <[reed]> that's the problem [16:45] damn, i can't send emails using my corporate address using thunderbird (or evolution), while i can with mutt. [16:46] smtp+auth with tb and evo, NOK. evo with sendmail, NOK. mutt with sendmail, OK. [16:53] [reed]: mmm, I hate how that's split [16:53] we need that toolkit prefs file [16:54] <[reed]> you just hate XULRunner [16:54] <[reed]> ;) [16:55] I hate that its something everyone's hacking around stuff [16:55] <[reed]> instead of filing upstream? [16:55] <[reed]> I agree with you there [16:55] it made me sad that only like 1/3 of things were filed [16:55] and that you'd been the one to file them :_/ [16:56] I mean, this is like 18 months of not bothering... [16:57] as for 16, well [16:57] does it need its own prefs file? [16:57] because, well [16:57] <[reed]> yeah [16:57] <[reed]> well [16:57] <[reed]> we should split out anything in toolkit to a separate prefs file [16:57] <[reed]> right now, all our apps have to duplicate the same prefs [16:58] I said that, what, four minutes ago? [16:58] why are you repeating my bitching? :P [16:58] <[reed]> I didn't see where you said something like "all our apps have to duplicate the same prefs" [17:07] [reed]: I said we need to do the toolkit prefs file [17:07] and, no, we can just stick stuff in all.js [17:07] that's the current standard [17:07] <[reed]> we do have non-toolkit apps [17:08] <[reed]> they might not appreciate that [17:09] why? [17:09] you think a few dozen prefs in all.js will impact those embeddors? [17:10] <[reed]> I dunno [17:10] <[reed]> maybe? [17:10] it'd be cleaner, but meh [17:10] <[reed]> I'll concede I'm making this up as I go. [17:10] don't do that [17:10] there's been enough of that to date :P [17:11] <[reed]> I blame you. [17:11] <[reed]> anyway [17:11] <[reed]> :) [17:11] <[reed]> so, are you coming to UDS? :P [17:11] don't think so [17:12] <[reed]> sad [17:12] eh [17:12] where's the next one? [17:12] <[reed]> no idea... will be announced on Friday of this one [17:12] ah [17:12] I just don't want to travel any more this year [17:13] my 40k miles of flying was my limit [17:13] you're not local ? [17:13] <[reed]> hey, I've done 25k this year, not including this upcoming trip [17:13] <[reed]> :) [17:14] <[reed]> Thanks Mozilla and Canonical for footing my travel bills! :) [17:14] <[reed]> fta2: he's Toronto-based [17:14] oh [17:14] <[reed]> all the Mikes save one are Toronto-based [17:15] <[reed]> I don't think we have any Mikes in MV now [17:15] mmm [17:15] Mikael Rogers? [17:15] <[reed]> oh, true [17:15] <[reed]> but he doesn't go by Mike, afaik [17:15] <[reed]> could be wrong [17:15] * fta2 is throwing thunderbird 3 and evolution through the window [17:16] 3? [17:16] bold [17:16] 3 & 2, all the same [17:16] <[reed]> [10:45:33AM] damn, i can't send emails using my corporate address using thunderbird (or evolution), while i can with mutt. [17:16] <[reed]> [10:46:54AM] smtp+auth with tb and evo, NOK. evo with sendmail, NOK. mutt with sendmail, OK. [17:16] out [17:16] <[reed]> France Telecom doesn't like open source. [17:16] <[reed]> ;) [17:16] [reed]: why'd you repaste that? [17:17] I was just noting that trusting your mail to Tb3 is bold :) [17:17] <[reed]> ah [17:17] <[reed]> ok [17:17] i trust ff3.1 for the web [17:17] yeah, but that's different [17:18] if I nuke my mail, I can't do my job really [17:20] all the same to me. and i have logs, backups and even copies of my corporate emails. [17:21] i'm going back to mutt for now [17:21] now i remember why i've been using it exclusively since 1996 [17:22] hehe [17:22] <[reed]> I personally use Sylpheed, as I'm dependent on a GUI-based mail client for some reason... though, Sylpheed is about the only thing that can handle my mail [17:22] <[reed]> Thunderbird fails miserably [17:23] <[reed]> considering the amount of e-mail I get faily [17:23] <[reed]> daily [17:27] isn't your quantity of mail faily regardless of your mail client? ;) [17:28] 99.5% of my incoming emails are spam. thanks to greylist/spamd/spamassassin/clamav, i'm just getting ~5% of spam at the end, 5% of 200~300 emails a day, 2/3 of mailing lists & bug tickets. procmail sorts those out, mutt can easily manage the rest. [17:30] asac, the new cairo is in. the next upload of xul will fail to build miserably [17:31] assuming 3.0 has the same problem as 3.1 === stevel_ is now known as stevel [18:59] hi [18:59] asac [18:59] as I was saying [18:59] hi huayra [18:59] I am interested in getting the swahili translation for ff3 going [18:59] I got resources and time for this [18:59] resources as in company backing [19:00] and I have a friend who is going to work with me on this [19:00] oh cool [19:00] my question is if it is better to use rosetta or to go the l10n patrh? [19:00] is there an official team for that language somewhere? [19:00] there is one, but they have not done anything since 1.0.3 [19:00] at least nothing is been released [19:00] a mozilla team [19:01] huayra: have you tried to talk to them? [19:01] I have contact with the lead, yes, but it seems to be lots of fractions in that team and nothing constructive coming out [19:01] https://bugzilla.mozilla.org/show_bug.cgi?id=300754 [19:01] Mozilla bug 300754 in Registration & Management "[sw-TZ] Kiswahili Firefox localization (Kilinux Team)" [Normal,Assigned] [19:02] huayra: if the team is somewhat active, it doesnt make much sense to use rosetta. unless the current team would be willing to do that [19:02] huayra: how do they maintain their translations? [19:02] huayra: you should email l10n@mozilla.com and sethb@mozilla.com for help getting things unbusted, IMO [19:02] basically no release has been done since 1.0.3 [19:02] do they have an (outdated) repository or something? [19:02] that's ages ago [19:03] yeah, I have a link, let me find it [19:03] huayra: do what mconnor said. once you know that you can take over the lead you can choose the tool you use to edit the stuff [19:03] there's a number of good translation tools for Mozilla [19:03] i think a requirement is to have a complete translation [19:04] yes, that is a requirement for being shipped as official, for obvious reasons [19:04] what should we use if we want the ubuntu community to contribute but also make upstream happy? [19:04] huayra: rosetta as a tool would helpful if you want to tap the ubuntu translator community [19:04] which sounds reasonable if the language is not a "major" one (excuse this word ;)) [19:05] mmm [19:05] I don't know why you'd translate for Ubuntu only [19:05] mconnor: well [19:05] but, if we want to make anyone happy and probably find a "framework" for such *minor* languages [19:05] ? [19:05] mconnor: we have lots of translators [19:05] mconnor: they all use rosetta. so if you put things in there it gets automatically done ... e.g. you dont need to build your own community [19:06] asac: that's not really an answer to "why translate only for Ubuntu" [19:06] I want to translate for everyone, not only Ubuntu, but rosetta (lp translations) has its adventages [19:06] so how can we get momentum and make everyone happy? [19:06] huayra: Axel and Seth can help here [19:06] mconnor: most likely a matter of interest [19:06] I want a translated ff3 in all platforms and tap the ubuntu community for its momentum too in the effort [19:07] mconnor: people just have to focus on something [19:07] like you focus on firefox [19:07] they're trying in the bug to resolve things, give them a shout, see what they can do [19:07] they have been discussing since 2005. I want some real work done [19:07] not just talking [19:07] * mconnor sighs [19:08] I am to use resources so I want results [19:08] yes, because that localization team is being weird [19:08] I'm not asking you to talk to to the existing team [19:08] if that means a one man show in rosetta so be it [19:08] mconnor: the idea is to do translations in rosetta and find a way to get that shoved over to "official" tree [19:08] but how can we fix things? [19:08] I'm asking you to ask Seth and Axel for help [19:08] we have contact with the team [19:08] because that's their job [19:08] huayra: yeah. talk to them ... about requirements and stuff [19:08] I am just asking you guys that know the real deal to find a solution [19:09] ok [19:09] huayra: reading the bug, they've laid everything out [19:09] I will then talk to Seth and Axel [19:09] the existing "team" doesn't seem to be doing anything [19:09] huayra: from rosetta point of view it would be interesting to get input on the exact formatting they require the translations to be done [19:09] yeah, I noticed that [19:09] they just own the team, but no progress is been done [19:09] so talk to them about restarting with a new team [19:09] they == who? [19:10] Seth and Axel are the l10n drivers for Mozilla, they coordinate l10n across all locales [19:10] I was thinking of the team, not of S & A ;) [19:10] so in conclusion [19:10] mconnor: they == Seth + Axel (and mozilla in general) [19:11] (if you asked for my they ;)) [19:11] is it possible to use rosetta and still get a usable translation for the upstream mozilla guys, or not? [19:11] huayra: it is possible. if there are things that need to be fixed, we will certainly do that [19:11] isn't rosetta just handling the PO files anyway? [19:11] its quite important for us to make things suitable for that [19:12] huayra: firefox doesnt have po files [19:12] heh [19:12] ok [19:12] I reckon I will just talk to Axel and Seth and find out [19:12] ok [19:13] thank you very much guys [19:13] huayra: its using xpi ... which is why its a bit more difficult. but rosetta has (beta) support for that. its just that we need more real-life [19:13] to streamline stuff ;) [19:13] so this could be a nice opportunity? [19:13] huayra: welcome [19:13] huayra: for sure. [19:13] I mean to test the xpi support? [19:14] huayra: right. [19:14] er [19:14] ok, interesting [19:14] it uses XPI for langpacks, yeah [19:14] but that's the package format, not the output format [19:15] mconnor: yeah. thats understood. its used as a synonym here. [19:15] yeah, xpi like in add-ons files [19:15] as long as it outputs something that matches the in-tree format so we can get it upstream, great [19:15] so, what do we do? [19:15] huayra: that's your call [19:15] huayra: talk to the experts though :) [19:16] shall I try to get thing s working with the team and see if we vcan use rosetta, or just import the whole thing from mozilla when the translation in their terms is done? [19:16] huayra: first sort out the admin stuff. then review the tools available on the market and decide [19:16] what are thos e tools? [19:16] huayra: Axel and Seth can give better recommendations [19:17] can you maybe point me to the tools that are used by other localization teams please [19:17] ok [19:17] where do I find those guys? [19:17] #mozilla ? [19:18] I'd email them [19:18] and they're not likely on freenode [19:18] sethb@mozilla.com and l10n@mozilla.com [19:18] Axel's in Germany, Seth's in California [19:19] thnks so much :) [19:19] omg ... my mailqueue was down again :( [19:19] thats scary when you dont know which mails didnt go out for how long :( [19:32] do you guys know how many string FF3 has? [19:33] huayra: i can look ;) [19:33] asac: focus on looking at the big set of patches I have issues with, please :) [19:33] huayra: around 2k, at last check [19:34] 1893 messages + 3821 messages [19:34] 5k? [19:34] 6k? [19:34] yeah [19:34] huh [19:34] maybe [19:34] I don't remember it being that high [19:35] but I don't translate :) [19:35] asac: you saw my link? [19:35] mconnor: yes. [19:36] mconnor: i will start to push bugs tomorrow. 2h a day ... should be just a few days. [19:36] mconnor: needs discussion should then be done in bugs [19:37] mconnor: good enough? [19:37] mconnor: [reed] already pointed out that 16 is required to move some classifier settings to toolkit [19:40] asac: there's better ways to do that than adding another file to parse, fwiw [19:41] so 3800 strings? [19:41] or just 2k? [19:41] kind of fell off the conversation... ;) [19:42] huayra: 3800 (toolkit) + 1600 (browser) [19:42] er 1800 [19:43] asac excuse my ignorance. I want FF3 translated and all translators speak English. Do I need to strictly translate just 1600 or do I need the toolkit translated as well? [19:44] huayra: toolkit is required [19:44] so 5400 strings is the translation requirement? [19:44] yes about that amount [19:44] thx [19:44] :) [19:44] 5600 [19:46] lol [19:47] asac: filing upstream bugs is the good first step, yeah [19:47] asac: some of this stuff is, well, unnecessary [19:49] asac: my biggest question was that in a couple of the patches you changed stuff inside of OSX #ifdefs, what was up there? [19:50] mconnor: most likely i tried to make the patch complete ... if that completely doesnt make sense for OSX i was just wrong ;) [19:51] asac: also, having a patch start with "supposedly this does X" is not ever something I want to see [19:51] ever [19:51] either it works or it doesn't :P [19:51] mconnor: which patch is that? [19:51] the debian compatibility thing? [19:52] yeah [19:54] mconnor: i wanted to write "i hate debian for this" there ;) ... and ended up with a more political wording. [19:54] mconnor: the patch obviously works ... otherwise it wouldnt be in there ;) [19:54] why take it then? [19:54] mconnor: background: we packaged xulrunner 1.9 and firefox 3.0 more than 6 month before debian did it. [19:55] mconnor: then they started to make life miserable by doing some slightly different decisions [19:55] asac: so, fun fact [19:56] mconnor: problem is that when debian says we install stuff at place X ... then all the packages that we automatically sync would either not work [19:56] or we would have to maintain a diff for them [19:56] man [19:56] you guys should stop depending on Debian [19:56] mconnor: and thats what debian guy did ;) [19:56] would make life so much easier [19:56] mconnor: after he noticed that i work for canonical :) [19:57] mconnor: previously debian xulrunner (1.8) had a patch system ... for 1.9 he eliminated that and now maintains stuff in a private git archive [19:57] man [19:57] mconnor: so when i want to understand what they did i have to look at the monolithic diff.gz [19:57] I'm having flashbacks [19:58] to the monolithic firefox-1.5 diff [19:58] :P [19:58] mconnor: firefox 3 is still monolithic. but thats eric as you might remember [19:58] mike agreed for ages that we want individual patches [19:58] until i started on ubuntu ;) [19:58] man... [19:58] those guys [19:59] so Mike has a private git repo, with a monolithic diff [19:59] and Eric has a private SVN repo, or something, with a monolithic diff [19:59] mconnor: yeah ;) [19:59] mconnor: i think eric has a public git now [19:59] ;) [19:59] quality software practices there [19:59] lots of transparency [20:00] * mconnor mumbles something about openssl under his breath [20:00] mconnor: eric doesnt understand. mike does, but wants to pretend he doesnt understand :) [20:00] mconnor: yeah. definitly a good example that we need to be much more skeptical about what debian does [20:01] mconnor: of course its somehow unique. the majority of debian folks are quite good [20:01] pkg-mono are nice! [20:01] problem is that they are no team players [20:01] everybody focusses on his pet-package [20:01] asac: yeah, I've noticed [20:01] and they think they're experts [20:01] and only cares about other things when it becomes a pain to locally workaround [20:02] that's my real worry with downstream [20:02] especially with mozilla, where we have too many dark corners [20:03] its just not sane to assume that 1-2 maintainers will know the right way to implement something [20:03] "Just because it works, doesn't mean its the right solution." [20:04] and stuff where you're adding features that only work in Ubuntu is sadmaking [21:09] fta: Hi [21:16] wiki, hi [21:16] the patches in the debian/patches dir,how are they made ?using quilt ? [21:19] quilt new my_new_patch.patch [21:19] quilt add mozilla/some/file1 [21:19] quilt add mozilla/some/file2 [21:19] quilt diff [21:19] quilt refresh [21:19] that's the basics [21:20] :) [21:20] fta: we released spicebird on 21st [21:21] excellent [21:23] of course, you need to edit your files *after* the corresponding add and *before* the refresh [21:26] fta: once i upload the files in lp via dput ,they get built themselves ? [21:26] do you mean in a ppa ? [21:26] yeah [21:27] then yes [21:40] fta: how long do these virtual monsters take ?40~45 minutes ? [21:47] hi. I have for my personal use patched the flashplugin-nonfree package to download and install the new naitive 64bit plugin on amd64. [21:48] i will send my patch to bug 299146, but what do you think would be a good version number? [21:48] Launchpad bug 299146 in flashplugin-nonfree "flashplugin-nonfree on amd64 should use pure 64 bit plugin" [Wishlist,Confirmed] https://launchpad.net/bugs/299146 [21:48] right now I use 10.0.12.36ubuntu2~10.0.d20.7 (where 10.0.d20.7 is the amd64 version) [21:51] wiki: they start to build quite instantly [21:52] wiki: then the take the time they need and then it takes about 30 minutes until you can access the .debs [21:52] asac: cool [21:52] paran: we will discuss during UDS how to properly package stuff up [21:52] paran: we still want the nspluginwrapper option as we also use that for i386 to prevent crashes of core firefox [21:53] asac: we use ccache and disctcc on dual core debian etch with j8 flags to build our moz builds. It takes around 10 minutes :) [21:54] wiki: if its more or less a full mozilla the builds usually take 25-30 minutes [21:54] if you do more... add something on top ;) [21:55] asac: to make a deb for hardy,will it be called a backport ? [21:56] asac: you mean use nspluginwrapper for all plugins on al arches then? [21:56] what if I mention as hardy in the changelog ,how will ppa interpret it ? [21:56] paran: yes ... (optional for user) [21:57] paran: so when amd64 is final we will not use nspluginwrapper for cross-arch ... only for out-of-process stuff [21:57] paran: but what we want in the long run will be discussed during UDS [21:57] (and how to achive that) [21:57] paran: so atm if you install flashplugin-nonfree and have nspluginwrapper installed on i386 it will use nspluginwrapper [21:58] asac: ok. if you do that then please make it on a per plugin basis. the current code always uses nspluginwrapper if it is installed [21:58] if you dont have nspluginwrapper it will not use it [21:58] paran: thats one of the points that is not yet clear [21:58] asac: I will want naitive flash, but might need the wrapper for other 32bit only plugins [21:58] paran: any ideas how the user is supposed to manage that? [21:59] we will discuss, but getting more ideas up-front will be helpful i guess [22:00] you could install both wrapped and unwrapped as alternatives [22:00] so you could use update-alternative to select [22:03] asac: I will put the nspluginwrapper code I ripped out back into my package. :) did you have any idea about the version name? [22:04] paran: depends on where this will end up [22:04] paran: update-alternative has to die imo :) [22:04] paran: but the idea of having both installed is nice [22:08] asac: hehe, why? I think alternatives is really useful, once you learn how to use it. [22:09] asac: I just want to put some sort of sane version number before I send the patch in. [22:11] even if you decide to change how stuff work some of my (small) patch might be usefull, like downloading different tarballs dependin on arch [22:13] paran: we dont need alternatives anymore. you can currently pick one out of many available plugins in ubufox ... this will hopefully later go into the main firefox UI [22:13] paran: like: http://people.ubuntu.com/~asac/tmp/alt1.png [22:13] paran: http://people.ubuntu.com/~asac/tmp/alt2.png [22:14] paran: we would get two entries there for adobe: 1) adobe (native) 2) adobe (nspluginwrapped) [22:17] asac: that would be nice. [22:18] paran: yeah. i like it too. only problem we have to sort is that when you install nspluginwrapper post-mortem we would have to wrap already installed plugins too [22:18] but that can be done quite diligently i think [22:19] (currently the wrapped stuff is only generated when you install flash after nspluginwrapper) [22:19] yeah, I know :) [22:19] however I would recommend keeping the alternatives link in addition to ubufox. there are other browsers that would need that [22:20] paran: not sure. its really just clutter. konqueror does that on their own anyway [22:20] epiphany is a use-case agreed [22:20] but then ... thats a missing feature in epiphany i guess and in the long run it will use nspluginwrapper [22:21] err [22:21] it will use webkit ;) [22:21] thats what i wanted to say [22:21] but well [22:21] alternatives dont hurt for this mechanism [22:21] its just that they regularly break on users system [22:29] would have been better if it were more integrated with dpkg, is is easy to mess it up with postinst/prerm scripts [22:32] paran: maybe. but dpkg is from hell ... so fixing that there isnt easy either ;) [22:32] anyway, please don't remove the alternative for plugins unless you at least get the plugin chooser into the "normal" firefox package. [22:32] paran: also even if you do it right, alternatives have strange behaviour [22:32] for instance if you --remove the last option it will remember that you selected nothing and when -install a new alternative it will not select the only one that exists then. [22:32] I don't install ubufox because it pulls in a ton of gnome stuff [22:33] paran: thats a different issue [22:33] apturl needs to be fixed [22:33] but yeah [22:33] but as i said. this stuff is so cool that it belongs in the main firefox UI anyway [22:35] :)