[00:29] <BUGabundo> nite
[02:56] <micahg> fta: xulrunner red is most probably due to missing configure flags in the build system, I'll try to sort it out
[07:25] <fta> micahg, doh! http://people.ubuntu.com/~fta/ppa-dashboard/ubuntu-mozilla-daily--ppa.html
[07:28] <micahg> fta: wow, even worse now :(
[07:33] <fta> dropped all jaunty packages from umd
[07:37] <micahg> wel,, maverick failed due to gnome/gtk updates, everything else due to patches
[08:08] <micahg> should I milestone bug 239952 as well? (I milestoned the linked bug from bmo)
[08:08] <ubot2> Launchpad bug 239952 in firefox-3.5 (Ubuntu Maverick) (and 9 other projects) "firefox - the associated helper application does not exist (affects: 58) (dups: 5) (heat: 329)" [Undecided,Invalid] https://launchpad.net/bugs/239952
[08:08] <micahg> oh, he's not here
[08:21] <fta> micahg, btw, the ucd-dev ppa is still scored down. each time i send something there, it takes days
[08:23] <micahg> hmm, looks all built now
[10:15] <edakiri> Where are system wide addons retrieved from for firefox-4.0 ?  There is only 1 listed: "Ubuntu Firefox Modifications" although previous branches of firefox see other addons.
[11:27] <chrisccoulson> asac - is anything using the files provided in xulrunner-1.9.2-testsuite?
[11:34] <asac> chrisccoulson: no package. however, the idea was that you can run the testsuite locally ;)
[11:34] <chrisccoulson> asac - oh, so we can get rid of it now then
[11:34] <asac> e.g. daily to check if there are regressions due to changes in the stack
[11:34] <asac> chrisccoulson: why?
[11:34] <chrisccoulson> firefox is running the testsuite in the buildd now
[11:34] <asac> well
[11:34] <asac> the idea is to run it in buildd and also be able to run locally
[11:35] <asac> i dont care ... but that was the idea
[11:35] <chrisccoulson> ah, ok
[11:35] <asac> we always were able to run on buildd ;)
[11:35] <asac> just not successful ;)
[11:35] <asac> chrisccoulson: is firefox succeeding?
[11:35] <chrisccoulson> asac - mostly. there are some xpcshell tests which fail because gconf doesn't run
[11:36] <chrisccoulson> and there are some reftest failures too, and some of those look like font issues
[11:36] <asac> the good thing is really to be able to run testsuite against different test envs
[11:36] <chrisccoulson> but, it's mostly ok
[11:36] <asac> e.g. your stack might have chnaged
[11:36] <asac> you want to run against just main ... or stable-updates ... or stable-proposed etc.
[11:36] <asac> yeah we also were down to just a few failures ... but those were hard to solve iirc
[11:36] <asac> and yes, font issues are likely
[11:37] <chrisccoulson> i expect the reftest failures will be quite hard for me to figure out ;)
[11:43] <asac> hehe
[11:43] <asac> thought you are idle anyway ;)
[11:43] <asac> chrisccoulson: how are things going in general? havent touched base for you for ages it feels ;)
[11:44] <chrisccoulson> asac - yeah, it's going pretty good thanks :)
[11:44] <chrisccoulson> i'm planning my work for natty now ;)
[11:46] <asac> whats the plan? ;)
[11:46] <asac> unbranding ffox again ;)?
[11:46] <chrisccoulson> lol
[11:46] <chrisccoulson> not quite ;)
[11:47] <chrisccoulson> the big task is going to be ff-4.0 :)
[11:47] <asac> jetpacks
[11:47] <asac> chrisccoulson: we have to talk about webgl + gles2
[11:47] <chrisccoulson> i want to try and get PGO builds working too
[11:48] <chrisccoulson> which is the motivation behind running the testsuite ;)
[11:48] <asac> pgo \o/
[11:48] <asac> so testsuite run is done for pgo profile?
[11:48] <asac> wasnt there a special test for pgo profiling?
[11:49] <chrisccoulson> i'm not sure if there is a special test or not
[11:49] <asac> if you run into problems wrt pgo profiling you can talk to our toolchain group in linaro ... especially on arm we would love to see this flying
[11:49] <chrisccoulson> cool, that's good to know :)
[11:49] <asac> chrisccoulson: there is a special test program for pgo ...
[11:50] <asac> its a proxy webserver thing that drives some test websites
[11:50] <chrisccoulson> ah, yes. that's used for the profiling
[11:50] <chrisccoulson> and it's also used for some of the normal tests too i think
[11:50] <asac> right
[11:51] <chrisccoulson> i guess i'm going to be learning a bit about toolchain issues over the next cycle ;)
[11:51] <asac> hehe
[11:51] <asac> chrisccoulson: do you know if all webgl landed for 4.0?
[11:52] <asac> what we need is a way to have the backends pluggable ... so you can also use gles on x86 etc.
[11:52] <asac> especially with gallium drivers i hope that in the end everyone can use gles
[11:52] <chrisccoulson> asac - i'm not too sure about what landed yet
[11:53] <asac> kk
[12:01] <chrisccoulson> asac - do you know who worked on the artwork parts of the abrowser branding?
[12:02] <chrisccoulson> it's currently broken in ff-4.0 with the recent changes to Help -> About dialog
[12:05] <asac> chrisccoulson: yes, ken ... he is gone now
[12:05] <asac> but that doesnt feel that difficult to take over by someone else
[12:06] <asac> i think it took like 5 minutes for ken
[12:12] <chrisccoulson> asac - cool, thanks. i guess i could have a go at it, i just wasn't sure if we had any svg's of the artwork (particularly the icon)
[12:12] <fta> !info ecb
[12:12] <ubot2> fta: ecb (source: ecb): code browser for Emacs supporting several languages. In component universe, is optional. Version 2.32-1 (lucid), package size 750 kB, installed size 4152 kB
[12:12] <fta> oh asac! so you're still alive, great :)
[12:13] <asac> fta: yes i am!!
[12:14] <asac> hidden in a dark room with 24/8 hours of work in 5 days ;)
[12:16] <fta> dpm, hi, i wanted to give the chromium translations a try, it will be a hell of a fight to achieve it
[12:16] <fta> asac, doing what? (if i may)
[12:17] <cyphermox> hi asac
[13:34] <dpm> hi fta. I'm not sure how they can all be tested without just installing Chromium in all languages. I can say that at least in Catalan they work :) Another option is to ask translators for feedback.
[13:35] <fta> dpm, no, i'm not talking about the desktop file, but the full langpacks
[13:36] <fta> integration into launchpad
[13:37] <fta> that would require a converter taking the complex grd and xtb files, outputing some pot and po files; and back
[13:38] <fta> i'm not sure what lp expects, and what it returns.
[13:38] <fta> also, i have no idea how to contribute that upstream
[13:39] <fta> and which branch to use (trunk or the stable branch)
[13:39] <fta> doesn't really make sense to translate stable, it's too volatile
[13:39] <fta> dpm, ^^
[13:41] <dpm> fta, I had a conversation about this with evan a while ago, and he was really interested. I explained how these could be done and IIRC he wanted to write a script or some code for the conversion, but on the last e-mail he told me that he was quite buys and he'd have no time to work on this unfortunately
[13:42] <dpm> fta, Launchpad only imports and exports gettext format
[13:42] <fta> yep, i was in Cc
[13:42] <dpm> ah, yeah, now I remember :)
[13:43] <dpm> so on import: POT file + PO files; export PO files, which are built as MO files in the language packs
[13:44] <fta> i figured out how to map the texts into IDs so at least the chromium->gettext seems doable
[13:44] <fta> i don't need the MOs, i need the .po files back
[13:46] <fta> even so, i'm still unsure how to proceed afterwards. once i have a po file with some changes, i can probably turn it into a xtb file, and create a patch
[13:47] <fta> but that's ugly
[13:54] <dpm> fta, I would have to re-read my own e-mail to remind myself about the format of chromium translations and such. But it's really cool that you've figured out the id mapping. If that would allow us to do the conversion chromium -> gettext, that would sort out the imports part. As per the exports, there are two things:
[13:55] <dpm> If chromium were in main, there would be the possibility of exporting the translations as PO files and have a script in langpack-o-matic that does the conversion po -> xtb in language packs
[13:55] <dpm> similarly to FF
[13:56] <dpm> If chromium remains in Universe, the only easy way is that upstream adopts LP as a translation tool, and that the conversion PO -> xtb is done upstream and the xtb translations are committed there
[13:57] <fta> ok so none of those two options are possible
[13:57] <fta> is?
[13:58] <fta> based on all the discussions, i concluded that chromium will never be in main
[13:59] <dpm> oh
[13:59] <fta> and we also know that upstream won't go toward gettext
[13:59] <fta> they use grit, which is some kind of xlst
[13:59] <fta> xslt
[14:00] <dpm> yeah, but I was not talking of them going fully to gettext, but rather doing the conversion only for translators
[14:00] <dpm> i.e. to get the translations imported into LP only
[14:01] <fta> dpm, for chromium in main, ask jcastro or the technical-board, they all voted against it
[14:01] <fta> dpm, the conversion is something we can do in the packaging
[14:03] <dpm> fta, from what you are saying, that'd be doable, I'm only concerned for the amount of extra work this would give to packagers (i.e. fetching periodically translations from LP, maintaining the conversion script, etc)
[14:04] <fta> dpm, chromium packagers? that's only me
[14:05] <dpm> fta, ok then s/packagers/you/ :-)
[14:06] <dpm> but I'd love to see Chromium translatable in LP
[14:06] <fta> dpm, well, i usually script that kind of repetitive tasks
[14:07] <dpm> fta, yes, I had assumed so. But even then, in my experience translations which are not handled in language packs tend to be a pain. Don't get me wrong though, I'd love to see Chromium translatable in LP.
[14:08] <dpm> Anyway, I'll be happy to help in what I can
[14:09] <fta> how active are the translators? it makes more sense to me to feed the xtb from trunk so upstream is more willing to accept them, but trunk means frequent updates
[14:10] <fta> well, maybe not that frequent, strings don't change that much
[14:10] <dpm> fta, it depends on the team. Some are extremely active. I think feeding from trunk would be fine. It's only a matter of properly communicating to translators that there are no string freezes and that it is a moving target
[14:11] <jcastro> fta: oh? when did they vote?
[14:11] <fta> jcastro, not a real vote but all the comments said so
[14:13] <fta> i still want the standing FFe exception thingy, but maaaaah, it seems there's no way
[14:15] <dpm> fta, to get started with this, once you've figured out the conversion, setting the LP project for translations the is only a matter of uploading the POT file + all existing PO files resulting from the conversion. Or alternatively, create a branch with the translations and check the automatic imports box in the chromium project in LP
[14:15] <lfaraone> chrisccoulson: did you get to my inquiry about Sugar Firefox.activity?
[14:16] <fta> dpm, all pot/po files flat in a branch?
[14:16] <dpm> fta, yeah, that's the usual layout for gettext projects:
[14:16] <dpm> po/chromium.pot
[14:16] <dpm> po/fr.po
[14:16] <dpm> po/es.po
[14:16] <dpm> ...
[14:16] <jcastro> fta: the conversation seems to be in the same state as last time
[14:17] <fta> dpm, and what will happen then? how do i get the results?
[14:17] <fta> jcastro, yes, since ~ early may, no progress
[14:20] <dpm> fta, first they'd be imported automatically for you (they'd be scanned from the bzr branch) and exposed to translators in similarly to https://translations.launchpad.net/simple-scan (obviously substituting chromium in the URL). Then there are two alternative ways you can get back translations done by translation teams: a) going to the project and requesting a tarball export: that will send you an e-mail with a link to a URL where you can fetch the
[14:20] <dpm>  latest translations in a tarball; or b) activating automatic exports, you'll get translations automatically committed to a branch of your choice (be it the same branch you used for the imports or another one)
[14:21] <dpm> I'd recommend b)
[14:23] <dpm> If they'd do the conversion to gettext on the upstream branch, we could even automatically import translations from the vcs import branch
[14:23] <dpm> s/on the upstream branch/upstream/
[14:24] <fta> are the exported po files similar to the originial ones ? (i mean, mininal diff suitable to be a patch?)
[14:27] <dpm> fta, I believe they are faily similar, but in any case diffs with gettext files are always ugly. If the POT template would change often, the source code references in the PO files would change often too, so that would make diffs bigger
[14:28] <fta> i guess i should just try and see i end up with ;)
[16:34] <chrisccoulson> lfaraone, i still didn't get your second mail :(
[16:34] <chrisccoulson> can you just paste it somewhere for now?
[16:34] <chrisccoulson> i'm not sure what's happening there
[16:34] <chrisccoulson> sorry
[16:35] <lfaraone> chrisccoulson: no worries. odd.
[16:37] <lfaraone> chrisccoulson: http://sprunge.us/DDib
[16:37] <chrisccoulson> thanks
[16:38] <lfaraone> s/activty/activity/g
[16:38] <fta> dpm, do you know a good description of the pot format?
[17:15] <jdstrand> fta: tested and copied chromium to -security and -updates
[17:20] <fta> jdstrand, thanks!
[17:26] <dpm> fta, yeah, in case you haven't looked at it already, the gettext docs are pretty good: http://www.gnu.org/software/gettext/manual/gettext.html#PO-Files
[17:27] <dpm> Gettext releases don't happen often, but the docs seem to be always up to date
[17:29] <fta> dpm, what about pot? is it the same format as po?
[17:30] <dpm> yeah, I believe only the header is slightly different - perhaps it's got an extra field? Let me check...
[17:33] <dpm> fta, they're the same I believe. Here you've got a couple of examples:
[17:33] <dpm> POT file: http://l10n.gnome.org/POT/gnome-control-center.gnome-2-32/gnome-control-center.gnome-2-32.pot
[17:33] <dpm> PO file: http://l10n.gnome.org/POT/gnome-control-center.gnome-2-32/gnome-control-center.gnome-2-32.ca.po
[17:33] <dpm> The PO file should show also a few fuzzy strings
[17:50] <fta> dpm, what when the project is multi-platforms?
[17:50] <fta> dpm, i have some conditional win / mac / linux strings
[17:56] <dpm> fta, I'd put them all in the template, regardless of the conditions. Generally strings in other projects are extracted at build time, but the tools that do the extraction (generally xgettext or intltool) extract everything from the source and put it in the resulting pot template
[17:57] <fta> dpm, can i use <tags> and variables like $1 ?
[17:57] <fta> http://paste.ubuntu.com/502211/  (line 184)
[18:02] <dpm> fta, you can put anything in there, the only caveat is that the gettext tools used for processing the files (generally msgfmt) will not do error checking unless the variable syntax is supported by the programming language the strings are extracted from
[18:02] <dpm> i.e. $1 strings will be checked for syntax on c-format messages
[18:03] <dpm> I need to step out for a bit, but in case we cannot catch up later, we can talk tomorrow
[18:03] <dpm> have a great evening!
[19:10] <davidascher> hi a..
[19:10] <davidascher> oops.
[19:10] <davidascher> hi all.
[19:10] <davidascher> David Ascher here, from Thunderbird-land.
[19:10] <davidascher> clarkbw and I are planning to attend UDS for the first time, and we're trying to figure out which days would be the most useful.
[19:11] <micahg> \o/ Mozilla attendance at UDS
[19:11] <micahg> chrisccoulson: do you know which days we're planning on having sessions yet?
[19:11] <davidascher> =)
[19:12] <davidascher> We've been talking to rick spencer, who'se setup https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-n-thunderbird-on-ubuntu for us
[19:12] <davidascher> but it'd be a shame to have TB discussed on Monday and Firefox on Friday, or whatever the extremes are.
[19:12] <davidascher> cause i'd like to attend the firefox discussions as well
[19:13] <davidascher> sorry bout that
[19:14] <davidascher> asac: ^^, btw.
[19:15] <micahg> davidascher: asac has moved on to other projects, chrisccoulson is the current team lead
[19:15] <davidascher> oh, ok, thanks.  didn't know.
[19:15] <dholbert> (my bad, I'd suggested asac since he was involved the last I'd heard :))
[19:16] <micahg> dholbert: no worries :)
[19:16] <micahg> davidascher: do any days work better for you, the sessions are mostly unscheduled
[19:17] <micahg> jcastro: Mozilla people coming to UDS ^^
[19:18] <jcastro> oh awesome, the schedule is still empty unfortunately, but we're sorting it.
[19:19] <davidascher> micahg: at this point, i don't know of any preference, no
[19:19] <jcastro> davidascher: if you're only attending for a few days make sure when you register to put the dates you'll be available: https://launchpad.net/sprints/uds-n
[19:20] <jcastro> then micahg just make sure all sessions have him marked as essential and it will force the system to schedule it on the days he's attending
[19:20] <davidascher> so the question is: when are the best parties? ;-)
[19:20] <jcastro> thu and fri. :)
[19:20] <jcastro> though one can argue that every night is the best party
[19:21] <chrisccoulson> micahg - i'm not sure about any scheduling details yet
[19:21] <micahg> chrisccoulson: k, do we want a session for each of the blueprints you made?
[19:22] <chrisccoulson> micahg - for ff-4 migration, definately. i want to talk about langpacks and stuff like that
[19:22] <davidascher> is there a list of the mozilla-related sessions?
[19:22] <chrisccoulson> for pgo - not so sure if that needs a session (i'm hoping to have the first PGO builds before UDS)
[19:22] <micahg> chrisccoulson: we can roll PGO into a generic team session
[19:23] <chrisccoulson> micahg - sure, that sounds ok
[19:23] <micahg> chrisccoulson: I subscribed you to the Thunderbird experience blueprint
[19:23] <chrisccoulson> the only reason i created a separate blueprint is that it's going to track the work to get the testsuite working with no failures
[19:23] <micahg> k
[19:24] <davidascher> I'm only seeing 18 blueprints at https://blueprints.launchpad.net/sprints/uds-n, is that to be expected?
[19:25] <jcastro> davidascher: yes, usually the pour in right around the week before release
[19:26] <jcastro> so this week and next week they should really start to come in
[19:27] <micahg> chrisccoulson: should the TB messsaging indicator be a separate session or rolled into one?
[19:28] <chrisccoulson> micahg - all part of the same session i think
[19:28] <micahg> k
[19:28] <davidascher> in this context, a blueprint is a proposed discussion session, not really a 'feature', right?
[19:29] <micahg> davidascher: yes, it's the topic of the session, some are single focused, some are multifocused
[22:24] <micahg> chrisccoulson: I'm glad we didn't go with Firefox 4 for maverick :)
[23:41] <micahg> [reed]: I thought the nss config bump isn't required for the new version but only if specific features are used which was the bug I originally blocked on
[23:50] <micahg> chrisccoulson: looks like NSS 3.12.8 is the minimum for the next round of Mozilla updates
[23:51] <chrisccoulson> micahg - oh, i should really pay attention to whats being landed really ;)
[23:51] <micahg> chrisccoulson: hasn't landed yet, but was just approved