=== davida is now known as davidascher
[08:01] <micahg> chrisccoulson: https://wiki.mozilla.org/Platform/2010-11-23 at the bottom (quarterly major updates)
[08:59] <chrisccoulson> micahg - that's not going to be fun
[08:59] <micahg> chrisccoulson: no
[08:59] <micahg> chrisccoulson: if they target 3, they might hit 6 which wouldn't work out too bad
[09:00] <micahg> they said 6 for 3.6 -> 3.7 which will end up being 4.0 one yr later
=== kancerman_ is now known as kancerman
[09:07] <kancerman> is xulrunner 2.0 beta too unstable for the Firefox 4 beta ??
[09:08] <micahg> kancerman: FF4 beta package doesn't use xulrunner
[09:08] <kancerman> d'oh! ... it's pretty much the -core part has replaced that then ??
[09:09] <micahg> kancerman: it has its own copy, I think the firefox-4.0 part has the xulrunner libs in it
[09:19] <micahg> chrisccoulson: do you think icedtea-web is worth getting in our packageset?
[09:20] <micahg> doko joked about it
[09:20] <chrisccoulson> lol
[09:21] <micahg> I guess that would imply some level of responsibility
[09:35] <micahg> chrisccoulson: I was thinking about asking the TB for an official SRU exception for Seamonkey, what do you think?
[09:41] <chrisccoulson> micahg - yeah, we could do. don't tell them we already bypass the normal rules though ;)
[09:41] <chrisccoulson> i've been treating seamonkey like firefox wrt to security updates ;)
[09:41] <micahg> chrisccoulson: well, they can just look at the history
[09:42] <chrisccoulson> yeah, i guess so :)
[09:42] <micahg> I think it implicitly might have an ok, I just would like to make it explicit
[09:42] <chrisccoulson> yeah, that makes sense
[09:43] <micahg> chrisccoulson: k, I'll copy you on it
[09:43] <chrisccoulson> thanks
[09:43] <micahg> will try before next week so it can be discussed at the meeting
[09:44] <micahg> chrisccoulson: is uploading lightning to security PPA (lucid) on your list?
[09:45] <chrisccoulson> micahg - it's not. we can't really push that out through security though, as it's not already in release
[09:45] <chrisccoulson> we'd need to do that through backports, which sucks
[09:45] <micahg> chrisccoulson: oh, right, good point :), I'll stage in tb-stable and we can request a backport after we upgrade TB :)
[09:46] <chrisccoulson> thanks
[09:46] <micahg> chrisccoulson: I should be on the backports team sometime next month :)
[09:46] <chrisccoulson> i'd just request the backport now tbh, the backports process tends to take a long time
[09:46] <chrisccoulson> cool
[09:46] <micahg> chrisccoulson: that's one of the things being worked on this cycle is improving the backport process
[09:47] <micahg> https://blueprints.edge.launchpad.net/ubuntu/+spec/ubuntutheproject-backports-n-bof
[09:48] <micahg> anyways, off to sleep I go :)
[11:57] <chrisccoulson> hi dpm. who do i poke about getting the new language pack xpi's in to launchpad, so that they end up in our next language packs?
[11:58] <chrisccoulson> (firefox is currently not translated at all in natty)
[12:11] <fta2> doh
[14:06] <dpm> hi chrisccoulson
[14:06] <dpm> sorry for the delay in replying
[14:06] <dpm> re: your question,
[14:06] <dpm> we were talking on the UDS session that danilo would help you with the imports, so that they can be integrated with the package upload process
[14:07] <dpm> However, danilo is away for two weeks. jtv is familiar with the firefox import/export code in LP, so he's probably the best person to talk to until danilo comes back.
[14:07] <dpm> jtv works from Thailand, so you'll generally find him in our mornings
[14:08] <dpm> Some more background info in case it's useful:
[14:08] <dpm> The way ArneGoetje did the uploads was fetching all language packs from mercurial and then using (I'm guessing) this script to import all upstream translations into LP:
[14:08] <dpm> https://code.edge.launchpad.net/~jtv/lp-translations-tools/trunk
[14:08] <dpm> (note that the script needs some tweaking right now IIRC, as it was written at a time where LP authentication worked differently than now.)
[14:09] <dpm> The other thing is that ArneGoetje was a member of the ubuntu-translations-coordinators in LP, so he had the permissions to upload templates. I guess, If someone from the mozilla team did the uploads, we'd just add him to the team
[14:09] <dpm> (e.g. cjwatson is also a member of the team because he also needs to upload the debian-installer templates manually)
[14:10] <dpm> I think this is mostly all you need to know - let me know if you've got more questions
[14:13] <dpm> oh, and here's some info on how to use the lp-translatioons-tools, with links to the documentation: https://wiki.ubuntu.com/UbuntuTranslationsCoordinators/Actions/LpTemplateAdministration#With%20the%20Launchpad%20Translations%20tools
[14:15] <dpm> and re: the language packs we want to start generating them at A-1. The exports from LP are already set up: https://translations.edge.launchpad.net/ubuntu/natty/+language-packs and pitti will take care of building them
[14:18] <fta2> dpm, hi, question: what's the usual practice regarding translation templates imports of big upstream projects? from release branches or from trunk?
[14:26] <dpm> hi fta2, it depends: right now in Ubuntu we import translations from the packages, not from branches. However, importing translations from mirrored branches is in the works, and I'm guessing we'll be taking them from trunk (taking as an example GNOME, which will be the first target). For projects not directly related to Ubuntu, the imports generally happen only if the maintainer decides to use Launchpad as an upstream for translations. Then it dep
[14:26] <dpm> ends on which branches he/she wants to import, and how stable they are. In any case, one could import several branches and set one as the translation focus. Here's an example: the ddtp project has several translatable branches, but sets maverick as the translation focus, so that translators know what's more important to translate:
[14:26] <dpm> https://translations.edge.launchpad.net/ddtp-ubuntu/+translations
[14:26] <dpm> If you are asking in the case of Chromium, I guess it'd be best to import trunk translation templates, but you know the workflow and the code best there
[14:28] <fta2> dpm, ok. the reason i asked is because i landed the lp translations in chromium beta earlier today. i discovered some bugs in my scripts while doing so (all fixed) and some interesting side effects
[14:28] <fta2> dpm, 1/ it means the more stable branches benefit from the updated translations upstream landed in trunk
[14:29] <fta2> dpm, 2/ same for the lp contributed strings (that was the initial goal)
[14:30] <fta2> dpm, and 3/ all strings that are no longer in trunk are lost
[14:31] <fta2> for 3/, i patched my script to preserve the upstream strings from the branch (that was a bug, where i fed empty strings, causing ftbfs)
[14:32] <dpm> fta2, I'm not sure I can follow, as I'm not familiar with the chromium code. First of all, a) how many branches are there in chromium upstream, and b) which one(s) are mirrored in LP and used for translations imports?
[14:33] <fta2> dpm, trunk, dev, beta, stable
[14:33] <fta2> dpm, none are mirrored (too complex, nested svn+git trees)
[14:33] <fta2> several dozens
[14:37] <dpm> fta2, ok gotcha. Can you remind me from which upstream branch you fetch the templates and translations you put in lp:chromium-browser/translations from?
[14:37] <fta2> dpm, trunk
[14:38] <dpm> ok, thanks
[14:40] <fta2> dpm, and i do that daily, at the same time as the daily builds. meaning i fetch trunk, extract the strings that i feed to lp, then fetch the export branch from lp, create patches in between that i land in my tarball, and submit that to the ppa builders
[14:41] <fta2> it's the same script doing the import/export/patching
[14:42] <dpm> fta2, ok, ack
[14:42] <fta2> but i only do the full cycle for the daily build. for the branch builds, i only fetch the lp exports, and merge that with what's in the branch
[14:46] <dpm> fta2, sorry if I'm asking an obvious question, but I'm just trying to wrap my head around it. So you're only creating translation patches for the daily builds. Are you doing it only there and not in the branch builds because it's easier to submit them upstream from there and it'd be pointless to have a second set of patches in the branch builds?
[14:51] <fta2> dpm, i'm doing everything with trunk to contribute upstream. it's immediately visible in the daily builds. but i also merge back to the branches (dev and beta, not stable yet, but soon)
[14:52] <dpm> fta2, ok, I get it, I was getting confused with the branch builds
[14:53] <fta2> but the templates moved a lot between trunk and stable (like stable is v7, trunk v9), so i gain fixed translations (either by upstream or by lp contributors), but lose obsoleted strings
[14:54] <fta2> loose
[14:55] <dpm> right
[14:56] <dpm> fta2, is that what you said earlier you were trying to work around with 3/ (i.e. avoid losing obsolete strings)?
[14:58] <fta2> dpm, yep. but i still loose the lp contributed strings that possibly happened in between (like in v8)
[14:59] <fta2> (digging into the older revisions of the lp export branch seems too complex)
[15:00] <dpm> right
[15:02] <jdstrand> chrisccoulson: hey. I am not really here, but I just committed a change to the firefox/4.0 branch for apparmor. it included a change to debian/rules, but I couldn't test it because bz534663_attXXX_normalize_distribution_searchplugins.patch no longer applies
[15:03] <dpm> fta2, so do you think we are at a point where we can widely announce Chromium translations? Or do you prefer to wait until that LP blocker bug 669831 is fixed?
[15:03] <ubot2> Launchpad bug 669831 in rosetta "obsolete translations exported to the branch (affects: 1) (heat: 6)" [High,Fix committed] https://launchpad.net/bugs/669831
[15:03] <jdstrand> chrisccoulson: well, maybe it does. I grabbed the natty source and plopped the debian/ from bzr into it
[15:03] <jdstrand> chrisccoulson: fyi only
[15:04] <chrisccoulson> jdstrand, thanks. i'll rebase that patch when i get a chance
[15:06] <jdstrand> chrisccoulson: fyi, I also committed the same patch to lp:firefox
[15:06] <chrisccoulson> thanks
[15:06] <jdstrand> sure
[15:06] <fta2> dpm, i first want to see the old templates disappear, remember?
[15:07] <dpm> fta2, ok, yeah, we talked about that yesterday.
[15:07] <fta2> dpm, once that is done, we can go
[15:08] <dpm> fta2, sounds good.
[15:08] <chrisccoulson> dpm - thanks for the info btw, i only just saw your response
[15:08] <dpm> chrisccoulson, ah, you're welcome
[15:09] <fta2> ok, i have to run. see you.
[16:16] <fta> i wonder if there's a way to inform browsers that a .txt file is in utf8
[16:16] <fta> chrisccoulson, dpm: ^^ any idea?
[16:17] <dpm> fta, hm, no idea, sorry :/
[16:24] <dpm> fta, I can't remember if I've already asked you this, what software did you use to create the diagram at http://people.ubuntu.com/~fta/chromium/chromium-translations.png ?
[16:25] <fta> dpm, a firefox extension, i don't remember the name. but i can check
[16:25] <fta> (i already told you iirc)
[16:25] <dpm> fta, ah, was it pencil, perhaps?
[16:28] <fta> yes
[16:45] <dpm> cool, thanks
=== ikonia_ is now known as ikonia
[17:12] <micahg> jdstrand: is there any reason you didn't add the mountinfo changes to the 10.10 profile?
[17:19] <micahg> chrisccoulson: something's not right with xul192.head: https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+build/2060964
[17:20] <chrisccoulson> hmmmm :/
[17:22] <chrisccoulson> i guess i need to set up a 32-bit chroot and figure out what's going on
[17:23] <fta> chrisccoulson, grr, xchat now opens firefox. i guess that's the thing we discussed yesterday
[17:24] <chrisccoulson> fta - yeah, probably
[17:24] <chrisccoulson> did you edit mimeapps.list?
[17:25] <fta> just did, doesn't work.
[17:25] <chrisccoulson> grrrr, couchdb
[17:25] <chrisccoulson> fta - perhaps xchat uses something else :/
[17:25] <chrisccoulson> i'm not too familiar with it
[17:26] <chrisccoulson> if it's not using g_app_info_launch_uris (or whatever it is),then it probably doesn't work
[17:26] <fta> even restarted it, nada
[17:27] <chrisccoulson> of course, i meant g_app_info_launch_default_for_uri ;)
[17:27] <fta> oh, i pasted your line, it was wrong. once fixed, it's better
[17:28] <fta> chromium.desktop vs chromium-browser.desktop
[17:28] <chrisccoulson> ah, ok. i didn't test it here, i literally just typed it in to xchat, so i made a guess at the names of the desktop files ;)
[17:35] <fta> chrisccoulson, which package is supposed to solve this mess? and when?
[17:36] <fta> is the system / prefs / preferred apps gui going to disappear?
[17:37] <chrisccoulson> fta - no, we basically need the new control-center (which has the changes to make the preferred apps dialog work)
[17:38] <chrisccoulson> but i'm not sure whether we're taking that yet, so we might just patch the current one to work
[17:38] <chrisccoulson> they removed the appearance settings from the new control-center, which i imagine will upset a lot of people
[18:52] <bobby_> Anyone mind me asking what the SpiderMonkey JS engine is?
[19:24] <ari-tczew> anybody here? I have a question
[19:25] <ari-tczew> could someone look at package libproxy in main? it looks like a sync, but only one thing wasn't applied in debina
[19:25] <ari-tczew> debian *
[19:25] <ari-tczew> remove libmozjs-dev from B-D, does it matter?
[19:29] <ari-tczew> ok, it;s to merge. libmozjs-dev doesn't exist in ubuntu
[19:47] <chrisccoulson> i'm getting really annoyed with couchdb now, it's just one crash after another
=== davida is now known as davidascher