[04:07] <ovnicraft> hello guys there is time limit where i request a pack translation to download from rosetta ? i did it 2 days ago still waiting?
[04:28] <wgrant> ovnicraft: There's an issue with the export queue at the moment. I'll ask the Translations devs about it when they come online in a few hours.
[11:18] <ahasenack> hi, question about recipes
[11:18] <ahasenack> they add a suffix of <distro>N to each package
[11:18] <ahasenack> for example,  landscape-client - 1.5.5.1~bzr305~lucid1
[11:18] <ahasenack> that is not in the version-revision "mask" we supply in the recipe
[11:19] <ahasenack> could that be changed/configured to the distro number instead of the name?
[11:19] <ahasenack> like,  landscape-client - 1.5.5.1~bzr305~10.04.1 in that example, perhaps
[11:21] <maxb> I don't see any fundamental flaw that would prevent such a feature, but I would ask why you'd want to.
[11:21] <maxb> Codenames are so much easier to comprehend
[11:31] <fta> henninge, hi, just Cced you to an email. I have a big problem with the chromium translations in launchpad
[11:32] <wgrant> ahasenack: We use the same format as official Ubuntu backports.
[11:32] <henninge> fta: I just saw it.
[11:34] <henninge> fta: can you give me a concrete example link?
[11:34] <fta> henninge, https://translations.launchpad.net/chromium-browser/translations/+lang/sl
[11:35] <fta> shouldn't have any need review
[11:36] <fta> same for es, zh-CN, and all the langs with strings contributed on lp
[11:36] <fta> it started a few days ago when upstream landed a new batch of strings, overwriting the ones in lp
[11:37] <fta> while it's not what i'm doing in the import
[11:39] <henninge> fta: so it happened before yesterdays roll-out?
[11:40] <henninge> roll-out of Launchpad, I mean
[11:40] <fta> henninge, well, i'm unsure. i know for sure upstream updated a lot of strings a few days ago, and this morning i got the email you saw
[11:40] <henninge> fta: so, AFAICT this is transatory.
[11:40] <henninge> transitory
[11:40] <fta> hm
[11:41] <henninge> we have a conversion script that still has to run once more after the roll-out to make all these "In Ubuntu" translations the current translation.
[11:41] <henninge> fta: it is not something that translators need to do manually.
[11:42] <fta> i'm supposed to land a new security update of chromium stable today, i wanted to ship it with the updated translations, but it's really messy at this point
[11:42] <henninge> sorry, that script should have been run as part of the roll-out but I guess it wasn't
[11:42] <henninge> jtv: I'll see that it gets run ASAP.
[11:42] <henninge> fta: ^
[11:42] <fta> ok
[11:44] <fta> it's very difficult to follow translations from launchpad :(
[11:45] <henninge> fta: what do you mean by "follow translations" ?
[11:45] <fta> the 1~2 days delay of the export makes creates lot of confusion
[11:45] <fta> -makes
[11:46] <henninge> fta: is that delay the reason why upstream translations are different from those in Launchpad?
[11:46] <fta> http://people.ubuntu.com/~fta/chromium/translations/trunk/converter-output.html numbers dont match
[11:47] <fta> so the lp export is either late, or bogus, or both
[11:47] <fta> henninge, ^^
[11:48] <ahasenack> maxb: about using codenames instead of numbers, what when we reach "z"? :)
[11:49] <henninge> fta: hm, I guess I am not familiar with the infrastructure you have around Launchpad Translations.
[11:50] <henninge> fta: let me chase up that script run first.
[11:50] <fta> henninge, i recently started to blog about this
[11:51] <henninge> fta: what's the blog url?
[11:51]  * henninge admits to be lousy reader of blogs ...
[11:52] <fta> henninge, i'm not done yet. but there are some info there: http://ftagada.wordpress.com/2011/01/08/chromium-translations-explained-part-1/
[11:52] <fta> henninge, http://ftagada.wordpress.com/2011/01/03/chromium-translationsdashboard/
[11:53] <fta> henninge, in my next article, i will cover this: http://people.ubuntu.com/~fta/chromium/chromium-translations.png
[11:53] <fta> henninge, oops, old link. this one: http://people.ubuntu.com/~fta/chromium/chromium-translations-v2.png
[11:55] <henninge> fta: that is a cool picture.
[11:55] <henninge> really helpful.
[11:56] <fta> henninge, thanks
[11:57] <henninge> fta: so this is purely for use in Ubuntu? Even after translations are done in Launchpad you will still get (old) translations from upstream, like happened just now?
[11:57] <fta> henninge, so basically, i produce patches for the 4 chromium branches: http://people.ubuntu.com/~fta/chromium/translations/
[11:57] <fta> henninge, no, i've been told chromium-os uses that too, and some other linux distros
[11:58] <fta> but it's possibly usable for mac and windows too
[11:58] <henninge> fta: I mean, were do the upstream translations come from and why are they different from what is done in Launchpad?
[11:58] <fta> except there's no chromium build of those that i know of, they use the official chrome builds
[11:59] <fta> henninge, upstream has an army of paid translators, but they focus on chrome, not chromium
[11:59] <henninge> ah, I see.
[11:59] <fta> so there are gaps
[12:00] <henninge> fta: I am asking because of the change in Launchpad Translations, the upstream imports will keep overwriting your translations., in a different way though.
[12:00] <henninge> worse, actually.
[12:01] <fta> henninge, i'm able to land some of the lp strings upstream, just not all: http://ftagada.wordpress.com/2011/01/07/more-chromium-translations-landed-upstream/
[12:01] <henninge> fta: you will have to move to the chromium-browser package in Ubuntu.
[12:01] <fta> henninge, not possible
[12:01] <henninge> jtv: why not?
[12:01] <henninge> fta: ^
[12:02] <henninge> (why do I keep typing jtv?)
[12:02] <fta> henninge, can't import it
[12:02] <henninge> fta: because of the missing export-to-branch feature?
[12:02] <henninge> on source packages?
[12:02] <henninge> hang on
[12:03] <henninge> you mean import upstream?
[12:03] <henninge> fta: ^
[12:03] <fta> the src tree is complex: http://src.chromium.org/svn/trunk/src/DEPS
[12:03] <fta> works with a py script
[12:03] <henninge> fta: no need to do that.
[12:03] <henninge> fta: the way it would work is this way:
[12:04] <henninge> fta: the imports from upstream will still go to the chromium-browser project, like they do now.
[12:05] <henninge> fta: the launchpad translations are done on the (latest) chromium-browser source package in Ubuntu.
[12:05] <henninge> that is how we tell upstream and Ubuntu translations apart in the new model.
[12:06] <henninge> fta: the problem is exporting those translations from the source package which I think is not possible for source packages yet.
[12:06] <fta> hm, it's not how my stuff work. from lp point of view, i'm supposed to be upstream
[12:06] <henninge> fta: but you are not. upstream has different translations to what you have in lp, right?
[12:06] <fta> i feed lp with a merge of converted upstream strings and lp strings i got from the last export
[12:07] <fta> i do the merge
[12:07] <fta> upstream is in grit format, you can't eat that
[12:07] <henninge> oh, so why are the string that got imported three days ago different from the strings in Launchpad?
[12:07] <fta> i feed you gettext
[12:07] <henninge> Becaues of the export delay?
[12:07] <fta> yep
[12:07] <henninge> I see.
[12:08] <henninge> so, using the source package would give you the merge functionality in Launchpad, your script would just need to do the conversion.
[12:08] <fta> did you read the url i just pasted? it's supposed to be clear for the grit/gettext part
[12:09] <henninge> you mean the picture?
[12:09] <fta> no, the part 1 url
[12:10] <fta> well, the picture too
[12:10] <fta> why isn't https://code.launchpad.net/~chromium-team/chromium-browser/chromium-translations.head usable as upstream?
[12:10] <henninge> fta: ah, no have not read that yet.
[12:11] <henninge> fta: it is.
[12:11] <fta> so i'm lost. it should work
[12:11] <henninge> fta: I think we are missing a picture here ... ;)
[12:12] <henninge> I mean, we (LP) should create a picture so people can see how it works now.
[12:12] <fta> the only element i don't control is what's coming out of rosetta (in the bzr export), and that seems to be the source of the problem
[12:13] <henninge> fta: that branch is the merged output of your script, right?
[12:13] <fta> right
[12:13] <fta> but it's a merge of upstream, and the lp export, which is now bogus
[12:13] <henninge> fta: the merging part is missing from the picture, btw.
[12:14] <henninge> fta: why is it bogus?
[12:15] <fta> didn't it just unconfirmed zillions of strings?
[12:15] <henninge> oh, ok
[12:15] <henninge> yes, it is missing a lot of string from Launchpad, atm. That' what you mean by bogus.
[12:16] <fta> i assume those will be dropped from the export, and then lost after my next merge
[12:16] <henninge> "those" = the missing strings?
[12:16] <fta> so we'll end up with the original strings from upstream, loosing the improvements from the lp translators
[12:17] <fta> those = the newly unconfirmed ones
[12:17] <henninge> fta: I thought only those within the export delay window?
[12:17] <henninge> fta: those I will fix today with the script run.
[12:18] <henninge> fta: which I will chase up now. We can sort out the rest later.
[12:42] <maxb> ahasenack: The use of codenames seems to be the prevailing convention within Ubuntu packagers. Therefore, they'll need to have solved that problem officially by the time we get to ZZ :-)
[12:49] <maxb> Is it just me or, is "Launchpad itself" experiencing a sudden spike in misdirected Ubuntu questions?
[12:52] <fta> henninge, would it be possible to schedule the export at a different time, to minimize the delay?
[13:05] <wgrant> maxb: Could that just be the sum of the questions that were previously split across the dozen launchpad-project projects?
[13:17] <Legendario> i am trying to download a project from launchpad but i am having a "Permission denied (publickey)."
[13:17] <Legendario> error
[13:21] <Legendario> does anyone know the answer for that?
[13:21] <maxb> Possibilities are:
[13:21] <maxb> You've not told launchpad about your ssh key
[13:21] <maxb> You have, but your ssh key isn't correctly available locally
[13:22] <maxb> You're trying to authenticate to launchpad with the wrong username
[13:25] <ahasenack> hi guys, I'm getting a "Server denied check_authentication" when trying to view a branch in LP (I'm logged in), but I can branch it fine with bzr branch.
[13:25] <ahasenack> lp link: https://bazaar.launchpad.net/~sidnei/landscape/standalone-combo-service/files
[13:26] <ahasenack> which fails
[13:26] <ahasenack> and
[13:26] <ahasenack> $ bzr branch lp:~sidnei/landscape/standalone-combo-service
[13:26] <ahasenack> Branched 2399 revision(s).
[13:26] <ahasenack> works
[13:27] <maxb> Are you absolutely sure you're authenticating as the same user over http as you are over ssh?
[13:27] <ahasenack> ahasenack, yes
[13:27] <ahasenack> https://launchpad.net/~ahasenack
[13:28] <ahasenack> I branch landscape branches every day
[13:28] <Legendario> maxb, how to i pass my ssh key to bzr
[13:28] <Legendario> ?
[13:28] <ahasenack> $ bzr lp-login
[13:28] <ahasenack> ahasenack
[13:29] <maxb> Legendario: Do you regularly use a ssh-agent?
[13:29] <Legendario> maxb, kind of...
[13:29] <ahasenack> hmm, let me try firefox...
[13:30] <maxb> Legendario: From the error message you gave, I can tell you are using OpenSSH. If your ssh key is loaded in a ssh-agent, OpenSSH should automatically see it and use it
[13:30] <ahasenack> same error with ff, phew
[13:31] <Legendario> maxb, is there a way to download the branch without using openssh? I just want to take a look at the code...
[13:33] <maxb> Legendario: To reverse the effect of "bzr lp-login", delete the launchpad_username line from ~/.bazaar/bazaar.conf. This will cause lp: URLs to use unauthenticated http:
[13:36] <Legendario> maxb, thanks
[14:15] <fta> henninge, how long will it take for your script to run?
[14:16] <henninge> fta: it is running but was blocked on post-roll-out database activity.
[14:16] <henninge> fta: admin is working on it.
[14:16] <fta> ok
[14:19] <henninge> fta: I am sorry but the admin is estimating that it will be blocked for another 4 hours or so.
[14:20] <fta> doh
[14:23] <henninge> this is really embarassing
[14:25] <fta> henninge, [13:52] <fta> henninge, would it be possible to schedule the export at a different time, to minimize the delay?
[14:25] <henninge> fta: not your specific export, it'd have to be all.
[14:26] <henninge> fta: where exactly do you see the delay?
[14:26] <fta> the thing is that the export always arrive 2~3h after my builds
[14:26] <henninge> I see
[14:26] <henninge> and you cannot change the time of the builds because upstream does that?
[14:27] <fta> henninge, it's a compromise to not not hammer the build farm
[14:28] <henninge> ok
[14:29] <fta> 4am chromium, 5am all mozilla, 6am various dailies, 7am network-manager, 5pm the chromium branches (less frequent), etc..
[14:29] <henninge> fta: when would you prefer to see the exports?
[14:29] <fta> 3am (paris time)
[14:29] <fta> so 2am utc
[14:32] <henninge> fta: mind you, we have another problem at hand in that uploads from upstream will now simply overwrite the translations in Launchpad.
[14:32] <fta> gasp
[14:33] <fta> doesn't it defeat the purpose of using lp to improve translations?
[14:36] <fta> henninge, ^^, but as i said, in the branch i feed to lp, i favor the lp translations during the merge (assuming lp exported them to me in the last export)
[14:38] <henninge> fta: well, the improvement comes when using a source package with the upstream project.
[14:38] <fta> ?
[14:38] <henninge> fta: the merging that you do, favorin lp translations, is supposed to be done in Lp.
[14:39] <fta> but here, lp is not able to do it, far from it
[14:39] <henninge> fta: the solution would be to upload the unmerged upstream translations (on gettext format of course) to the project but do the translation in package.
[14:40] <henninge> fta: not that far. it is just missing one feature to nicely fit in your diagram.
[14:40] <fta> http://bazaar.launchpad.net/~chromium-team/chromium-browser/chromium-translations-tools.head/annotate/head%3A/chromium2pot.py
[14:41] <henninge> fta: currently you cannot pull translations from a source package using bzr, like you can from a project
[14:41]  * henninge looks at file.
[14:41] <henninge> fta: yes, I am aware of the format issue and you have solved that nicely.
[14:42] <henninge> fta: the issue is hand now is telling upstream and Ubuntu (LP) translations apart.
[14:42] <fta> i do it in the script to create both my dashboard and the patches
[14:44] <henninge> fta: yes but only because so far LP gave you that distinction within the project. That is gone now.
[14:45] <henninge> you need to use a project and a source package.
[14:45] <fta> henninge, no, i'm still able to do it. i have the reference file from upstream, everything else is from lp
[14:45] <henninge> It will actually work out nicer were it not for the missing bzr export on source packages.
[14:46] <henninge> fta: I think there is a misunderstanding here.
[14:46] <henninge> fta: you only need to change two things in you setup:
[14:47] <henninge> 1) stop merging LP translations into upstream. That'll be done in LP
[14:47] <henninge> 2) pull translations from a different branch. Or rather, point the source package exports to that branch.
[14:47] <henninge> the rest works just like now.
[14:48] <henninge> 2) is not even a real change.
[14:49] <fta> i understand 1), it's disturbing my multi-branches setup, but it's probably doable. i don't understand 2)
[14:49] <fta> i already have 2 branches, one for the import another one for the export
[14:54] <henninge> fta: right, as I said, it is not really a change
[14:55] <henninge> fta: what about the multi-branches setup?
[15:06] <fta> henninge, i feed lp with strings from trunk, but i also have 3 other branches (dev, beta, stable) so i merge everything down (meaning they benefit from the improvements of both upstream and lp)
[15:06] <fta> a kind of automatic backport
[15:07] <fta> that's visible in my diagram
[15:09] <henninge> fta: you can keep merging those, that's fine
[15:09] <cnd> mrevell, I've been roped into giving a 1 hr presentation at the India Ubuntu Developer Day for bzr and lp
[15:09] <cnd> jml said you might have some presentations I could use or cut and paste from?
[15:09] <henninge> fta: just don't merge the lp translations you export in (3) back with them.
[15:09] <henninge> that part will be don in LP
[15:10] <fta> henninge, yes, but it means i have to do things differently between my trunk builds and my branches builds
[15:10] <fta> so it's not transparent to me
[15:10] <mrevell> Hi cnd. I'm not sure we have anything that's up to date. I don't have anything to hand. https://launchpad.net/+tour would be a good starting point ... When is the event? I might be able to get something together in time.
[15:10] <henninge> fta: hm, I don't think I understand.
[15:11] <henninge> fta: actually, it would also work if you keep it as it is.
[15:11] <henninge> but you wouldn't *have* to do it.
[15:12] <fta> henninge, btw, i think you confused me too. i'm definitely not feeding lp the merges
[15:12] <cnd> mrevell, two weeks
[15:12] <cnd> from today even, I think
[15:13] <henninge> fta: oh, you do not?
[15:13] <mrevell> cnd, 27th Feb?
[15:13] <fta> henninge, but i populate both the pot and all po-s with empty strings when i get a new string from upstream
[15:13] <mrevell> cnd, er, jan
[15:14] <cnd> mrevell, yep
[15:14] <fta> henninge, ex: http://bazaar.launchpad.net/~chromium-team/chromium-browser/chromium-translations.head/files/head%3A/inspector_strings/ vs http://bazaar.launchpad.net/~chromium-team/chromium-browser/chromium-translations-exports.head/files/head%3A/inspector_strings/
[15:15] <fta> henninge, (this template has no upstream translations at all)
[15:15] <mrevell> cnd, I can pull something together on the 26th and email it over to you, if that's okay. Can you email me, please, with the sort of level you're looking for? Also, how much time you have etc.
[15:15] <cnd> mrevell, thanks a bunch!
[15:16] <cnd> I'll email too, but it's 1 hr and it's aimed to give an overview of bzr and lp usage for new devs
[15:19] <cnd> mrevell, grrr... I just got an email saying they want the presentations by the middle of next week
[15:19] <cnd> I don't mean to dump any work onto you
[15:19] <cnd> I'm quite happy to cut and paste from other presentations or do it myself
[15:20] <mrevell> cnd, I'm afraid I won't be able to make that deadline. What I can do, though, is email you some text etc. I'm working on a page for the Ubuntu developer portal that will feature much of the same content.
[15:20] <cnd> mrevell, that's great
[15:21] <cnd> mrevell, I just sent you an email in case that helps
[15:22] <mrevell> Thanks cnd. I'll drop you a mail tomorrow.
[15:22] <cnd> cool
[15:36] <danilos> fta, hi, I've heard of the issues with Chromium translations, do you have a minute to discuss it?
[15:37] <fta> danilos, sure
[15:37] <danilos> fta, so, I've seen that LP translations are getting turned into suggestions on imports, right?
[15:37] <fta> danilos, did you read what have been said above?
[15:38] <fta> yep, that's right, that's what translators are complaining about
[15:38] <danilos> fta, no, I've joined the channel only 20 mins ago, sorry
[15:38] <fta> oh
[15:38] <danilos> fta, right, but this shouldn't have changed _much_ in Launchpad (i.e. that was happening in the past as well)
[15:39] <fta> danilos, some langs were at 100%, now they have hundreds of strings moved back to suggestions
[15:40] <fta> i understand their frustration
[15:41] <henninge> danilos: they have not become suggestions.
[15:41] <danilos> fta, right, so do I
[15:41] <henninge> danilos: they are "In Ubuntu", i.e. other side translations.
[15:41] <danilos> henninge, have we run the migrate current flag script for the rollout?
[15:42] <henninge> danilos: no, we have not. It is currently blocked on slave rebuild.
[15:42] <danilos> henninge, have we run it just before the rollout?
[15:42] <henninge> danilos: I didn't
[15:42] <henninge> danilos: I am aware that that is the reason for the current situation.
[15:43] <henninge> but once the script has run, fta's next upload from upstream will overwrite the lp translations.
[15:43] <danilos> jtv, did you by any chance arrange a run of migrate-current-flags script before the rollout?
[15:43] <danilos> henninge, just like it did in the past, yes
[15:43] <jtv> danilos: henninge did
[15:43] <danilos> jtv, henning says he only scheduled it for post-rollout
[15:43] <henninge> jtv: no, I didn't
[15:43] <danilos> we should have done this during the rollout
[15:43] <henninge> I know, we forgot.
[15:43] <danilos> henninge, right, ok
[15:44] <jtv> I definitely did... henninge: I thought you said the losas were looking into it?
[15:44] <henninge> jtv: now, but now is after the roll-out
[15:44] <jtv> yes
[15:44] <henninge> I only requested it today.
[15:44] <henninge> after I saw fta's problem.
[15:44] <danilos> fta, ok, so this should be fixed for chromium as soon as our migration script runs, but unfortunately it can't run until DB slave is rebuilt (which sometimes takes up to 24h)
[15:44] <jtv> ah, I missed the "before" part
[15:45] <henninge> danilos: mthaddon estimated another 2.5 hours.
[15:48] <danilos> fta, anyway, translations should be fixed and it's our fault that you hit a problem; hopefully as fast as today, but definitely by tomorrow
[15:50] <fta> danilos, i'd like to understand what happens when upstream add/update a translation after it has been added/updated in lp
[15:50] <fta> which one will prevail?
[15:50] <danilos> fta, upstream one
[15:50] <fta> danilos, gasp :(
[15:50] <danilos> fta, but that's how it worked in the past as well, except in a very special case
[15:51] <danilos> fta, we had "prefer upstream" policy for quite a while (i.e. 2 years I think)
[15:51] <fta> danilos, some ubuntu translators changed hundreds of upstream translations
[15:51] <fta> claiming the upstream ones are not that good
[15:52] <danilos> fta, right, that's the case where we kept Launchpad translations
[15:52] <danilos> fta, and we still do if they are done on Ubuntu
[15:53] <fta> once again, i'm lost
[15:54] <danilos> fta, sorry about that
[15:54] <fta> let's take an example: we start with string = "Foo" / string[fr] = "Truc" coming from upstream
[15:55] <fta> someone comes in lp and change it to string[fr] = "Better Truc"
[15:55] <fta> it takes over
[15:55] <fta> then upstream lands string[fr] = "different Truc"
[15:55] <danilos> fta, "different Truc" will be accepted as the translation then
[15:55] <fta> but it's still considered worse than the lp translation, then what?
[15:56] <danilos> fta, then translators should either push the better translation upstream, or diverge only in Ubuntu; launchpad.net/chromium-browser should match upstream directly, but Ubuntu translations can differ
[15:56] <henninge> fta: no, "Better Truc" will remain because it was delivertyl changed in LP.
[15:57] <henninge> fta: only if we started with no translation cominf from upstream, then the first translation coming from upstream would replace "Better Truc"
[15:57] <danilos> henninge, ?
[15:57] <henninge>  we start with string = "Foo" / string[fr] = "Truc" coming from upstream
[15:57] <henninge> sorry, wrong
[15:57] <henninge>  we start with string = "Foo" / string[fr] = "" coming from upstream
[15:58] <henninge> no French translation
[15:58] <henninge> someone comes in lp and change it to string[fr] = "Better Truc"
[15:58] <fta> (i started with only ~60% of my strings translated, so i have both cases)
[15:58] <henninge> then upstream lands string[fr] = "first upstream Truc"
[15:58] <danilos> heh, fta, as you can see, we are as confused as you are as to exactly what we have implemented
[15:59] <fta> lol
[15:59] <henninge> fta: in *that* case, upstream will replace "Better Truc"
[15:59] <jtv> So you'll end up with "first upstream Truc."
[15:59] <danilos> fta, ok, so we'll make sure that nothing breaks in a serious way for you and chromium
[15:59] <jtv> Because lp assumes that the translation it already had wasn't there because LP had a better translation, but only because there wasn't one upstream.
[16:00] <jtv> But LP still likes upstream and Ubuntu to share the same translations unless there's a deliberate indication that they _should_ differ
[16:00] <danilos> fta, we obviously need to wrap our heads around all the specifics
[16:00] <fta> jtv, and how can someone indicate that?
[16:00] <danilos> fta, fwiw, the behaviour you relied on never really worked for some cases (i.e. those that didn't already have translations upstream)
[16:01] <danilos> fta, generally, the idea is that unless there was intentional overriding of an upstream translation, upstream translation is better
[16:01] <jtv> fta: I'm actually describing the old situation.
[16:01] <henninge> jtv: we all are, more or less.
[16:01] <fta> danilos, my problem is that i can only land (upstream) strings for some templates, the other templates are locked by Google for their paid translators
[16:02] <fta> yet, our translators think they can do better
[16:02] <fta> dpm, (correct me if i'm wrong, but that's the feeling i got)
[16:03] <danilos> fta, right, I understand your problem; fwiw, the easy solution would be to just upload identical templates to ubuntu source package and point translators there; you'd lose the ability to work with branches though :(
[16:03] <fta> otherwise, why would someone bother changing 500~1000 strings?
[16:04] <danilos> fta, yeah, and I agree with that, it's just that they should do it in Ubuntu "namespace" on LP then
[16:04] <danilos> fta, if we didn't want translators to have an ability to diverge from upstream when they believe they can do better, we probably wouldn't need Launchpad in the first place
[16:06] <danilos> fta, however, the previous functionality was better for your particular needs, but was far from perfect and very arbitrary (compared to what translators want)
[16:07] <fta> i don't understand my options here. what does this "upload identical templates to ubuntu source package" mean in my case?
[16:07] <fta> lp is not reading my source package afaik
[16:08] <danilos> fta, it would mean either packaging them statically in source package builds, or uploading them through web UI
[16:08] <jtv> Well I take it that LP is reading the source package, but no translations are imported from it because they're not in gettext.
[16:09] <jtv> danilos: why not generate (and import) gettext templates based on the native ones during package build?
[16:09] <jtv> That would automate the procedure, and also give us the right version of the templates for the package even if they may differ a bit from the upstream ones (which presumably will come in more directly).
[16:10] <fta> i don't have the gettext files in my source package, they live only in a dedicated bzr branch
[16:10] <danilos> jtv, because that might be too hard: fta is using custom scripts and they are not available on buiilders
[16:11] <henninge> fta: your script would have to be integrated into the package builds.
[16:11] <henninge> actually, that'd be the cleanest solution.
[16:11] <jtv> I was thinking of keeping the script in the package.
[16:11] <danilos> jtv, ideally, we'd make use of your old upload scripts so fta automatically updates it whenever he updates it in a bzr branch
[16:11] <jtv> And having it run as part of the package build.
[16:11] <jtv> danilos: I was hoping to retire those scripts—I think they're not even up to date with our latest sign-on setup!
[16:12] <danilos> jtv, henninge: while we like that as a solution, I can imagine chromium-browser packager (fta) doesn't
[16:12] <jtv> as luck would have it, I hear he's around at the moment!
[16:12] <danilos> jtv, right, but at the moment we don't have anything better for source package uploads
[16:13] <jtv> Well we have one better thing for source package uploads: the conventional procedure.
[16:14] <jtv> If the package build could include a gettext conversion of the template(s), it'd just get imported like the rest, right?
[16:14] <fta> well, what i'm doing is supposed to be better than what we have for mozilla, for which we (packagers) don't have enough control to ship updated translations when we need to
[16:14] <fta> chrisccoulson, ^^
[16:14] <chrisccoulson> hi fta
[16:15] <fta> chrisccoulson, (speaking about chromium translations)
[16:15] <chrisccoulson> ah, ok
[16:15] <danilos> fta, right, it is definitely better in a few ways, the only problem is that translations do not happen on ubuntu source package and Launchpad will mistreat them sometimes then
[16:16] <danilos> fta, however, for firefox, new template is built on package build, which is better overall
[16:16] <micahg> chrisccoulson: you mind if I start a new changelog entry for the dailies, that huge mess is getting hard to track
[16:16] <chrisccoulson> micahg - yeah, sure
[16:16] <micahg> chrisccoulson: thanks
[16:16] <fta> danilos, in chromium too, i create my lang pack at build time
[16:17] <fta> packS
[16:17] <fta> i have 50+ of them
[16:17] <danilos> fta, in regular ubuntu source package builds?
[16:17] <fta> danilos, yep, but not in gettext format
[16:18] <danilos> fta, nice, I assume you manually integrate LP translations though
[16:18] <fta> yet i can have the grit2gettext converter in the package
[16:18] <fta> there's nothing manual in my packages ;)
[16:18] <fta> i'm not a robot
[16:19] <danilos> fta, that'd probably be cool, and also note that you don't need to convert translations to PO format in the source package as long as you are doing it in the upstream projct
[16:20] <danilos> fta, heh, well, I thought "manual" as in it's not done by Launchpad or packaging logic directly (I know builders are firewalled so they wouldn't be able to get PO files from LP)
[16:20] <danilos> fta, i.e. *you* automated it on your side :)
[16:21] <fta> danilos, http://bazaar.launchpad.net/~chromium-team/chromium-browser/chromium-browser.head/annotate/head%3A/debian/rules   line 615++
[16:22] <fta> so i do the merge when i create my source tarball
[16:23] <danilos> fta, wow, that works... I knew we did open codehosting access from PPA builders, didn't know we did it for Ubuntu source package builders
[16:23] <fta> ?
[16:24] <danilos> fta, cool, then I suppose it'd be best to just construct a .pot file and let pkgstriptranslations upload it to Launchpad
[16:24] <fta> i do that on my own hardware
[16:25] <fta> i can ship those gettext files in the .orig.tar.gz, i'm already generating them anyway
[16:25] <danilos> fta, ah, that's what I was saying: regular ubuntu package builds which happen on Launchpad wouldn't have access to lp:~chromium-team/chromium-browser/* branches
[16:25] <fta> that's just 45M more
[16:25] <danilos> fta, right, that'd probably work, but as I said, you only need to include the POT file
[16:26] <danilos> fta, PO files won't mind, as long as you keep them imported on the upstream project
[16:26] <danilos> won't mind -> won't be a problem (or LP won't mind :)
[16:26] <jtv> We'll still have to worry about exporting the package translations to a branch I guess.
[16:26] <danilos> fta, and "probably work" -> definitely work
[16:27] <fta> remember i'm interested in having trunk translated, and this is only in a ppa, does pkgstriptranslations work in PPAs now? i thought it was disabled
[16:27] <danilos> fta, no, it doesn't
[16:27] <danilos> fta, I thought you were the ubuntu chromium-browser packager as well?
[16:28] <fta> i am
[16:28] <fta> no one seems crazy enough to give me a hand :(
[16:29] <jtv> This is where, in the military world, the entire platoon takes a discreet step backwards
[16:29] <danilos> fta, right, so basically, the solution we are proposing is including a .pot file on the ubuntu chromium-browser package build, and doing translations on https://translations.launchpad.net/ubuntu/natty/+source/chromium-browser instead of translations.lp.net/chromium-browser
[16:29] <danilos> fta, that way, ubuntu translators can have their changed translations
[16:30] <fta> danilos, if i understand correctly, that would mean translating stable (which not even upstream does, too old, too late)
[16:32] <danilos> fta, hum, so you are only interested in translations of the tip?
[16:32] <fta> i still don't understand why lp can't consider as upstream the bzr branch i update for it
[16:32] <danilos> fta, where do translations from LP end up in which are not accepted upstream?
[16:33] <danilos> fta, it does
[16:33] <fta> danilos, everywhere, tip, dev, beta, stable: http://people.ubuntu.com/~fta/chromium/chromium-translations-v2.png
[16:34] <fta> there's now a 6 weeks cycle between trunk and stable, so it's too short for most translators
[16:36] <danilos> fta, so basically you want to manage a translations diff from upstream which is not directly tied to ubuntu packages?
[16:37] <danilos> fta, (whenever it's tied to ubuntu packages, we should just include appropriate .pots on all ubuntu packages and it will just work)
[16:37] <fta> danilos, correct, the diff is shipped in the source tarball, and exposed to upstream and anyone interested there: http://people.ubuntu.com/~fta/chromium/translations/
[16:38] <dpm> fta, (sorry for the late reply, I've just read the scrollback). As per your question "yet, our translators think they can do better", I can confirm it in the cases I can understand the language. I had a look at the Launchpad corrections for Spanish and they were genuine fixes, which where better than the original paid-for translations. In Catalan, we'll be doing some changes too.
[16:39] <fta> dpm, thanks for confirming it :)
[16:39] <dpm> no worries :)
[16:39] <dpm> danilos, btw, pkgstriptranslations would not work for chromium, because it's in universe
[16:39] <danilos> fta, right, unfortunately, LP is not designed for that use case yet (even before this change, this change just makes it more obvious)... I'll have to think about the best that we can achieve and I'll try to come back to you
[16:39] <danilos> dpm, ah :(
[16:39] <danilos> dpm, though, that's something that we can probably easily work-around in LP
[16:40] <fta> dpm, btw, i'm about to update chromium stable (security fixes), and translation wise, i will whitelist basque and galician. other new langs don't have enough coverage
[16:41] <dpm> fta, that sounds fine. Would you mind sending a notice on the launchpad-translators mailing list about this? This should let people know why their new languages did not make it yet and encourage them to complete them
[16:42] <dpm> danilos, yeah, but right now there is no chromium template in Ubuntu. It's just an upstream package (and I think this is fine as it is for now).
[16:42] <dpm> upstream project in LP, I meant
[16:43] <fta> dpm, sure, i will, the only two lang that won't make it in this stable update are asturian (only 5.8%) and uyghur (1.4%)
[16:43] <dpm> fta, thanks.
[16:43] <fta> following this: http://people.ubuntu.com/~fta/chromium/translations/stable/converter-output.html
[16:43] <danilos> dpm, right, but unfortunately, LP can't handle a "forked" translation for a project perfectly yet (which is basically what we need here)
[16:43] <fta> that's the backport of the lp translations (from trunk) to the stable branch
[16:45] <fta> this is for chromium v8. hopefully, we'll have some 100% by chromium v10
[16:45] <fta> dpm, ^^
[16:48] <dpm> fta, ok
[16:50] <fta> dpm, i hope this cut off makes sense. imho, it's better to have no translation at all rather than just a handful of strings here and there)
[16:50] <fta> which looks weird
[16:54] <dpm> fta, I think there are advantages on both. As long as translators know that they need to reach a cut off, that's fine. The important thing for me is always that everyone is in the loop
[16:55] <fta> dpm, i will blog about it, and inform the list. the 4 ppa still have everything though.
[16:56] <NCommander> hey all, I have a private project which the NDA has been lifted on. Currently everything is grouped under one project, and I'd like best pratices to moving everything from one project to a bunch of projects under a superproject,
[16:56] <dpm> fta, awesome, thanks! I'll forward your post to the translators Facebook page as well
[16:56] <fta> dpm, the thing is it's hard to explain what should be done 1st, the grit format is way more powerful than gettext
[16:57] <dpm> fta, hmm, it's not really, is it? grit does not support plurals, which is a very basic feature that gettext has supported for ages
[16:57] <fta> dpm, and lp also has its own limitations, so the bar is quite higher than in regular gnome projects
[16:58] <fta> dpm, conditions, if os == "linux2" and lang in [ 'ar', 'ug' ] blabla
[16:59] <fta> dpm, and the various fallback choices
[16:59] <hrw> hi
[16:59] <hrw> was upload processor disabled again?
[17:01] <StevenK> No?
[17:02] <soren> Oh, noes.
[17:02] <soren> Err... Wrong channel.
[17:03] <hrw> I uploaded linux 2.6.37-12.26ppa1 to https://launchpad.net/~hrw/+archive/tymtyrymtym/+packages and there is no sign of it or email with rejectsion message
[17:03] <StevenK> When was it uploaded?
[17:04] <StevenK> Roughly, I mean
[17:04] <dpm> fta, yeah, I can see the advantages of conditional translation (and agree on that), but still, the fact that it's missing plural forms is a pretty basic lack of functionality
[17:04] <hrw> 21 minutes ago
[17:05] <bigjools> hrw: it was rejected
[17:05] <bigjools> Unable to find linux_2.6.37.orig.tar.gz in upload or
[17:05] <bigjools>  distribution.
[17:05] <bigjools> check your spam folder
[17:05] <hrw> thx
[18:17] <leoquant> we have an old project: Dutch Lernid Development linked to:  https://launchpad.net/~lernid-devs  how to remove such a dead link?
[18:30] <danilos> chrisccoulson, hi, do you happen to know where can I find 4.0b9 firefox?
[18:30] <chrisccoulson> danilos, it's in natty now
[18:30] <danilos> chrisccoulson, I actually care about translation xpis but can't find them
[18:30] <chrisccoulson> ah
[18:30] <danilos> chrisccoulson, right, and because of the tight limits, I can't test with 4.0b8 XPIs
[18:31] <chrisccoulson> perhaps mozilla haven't spun their b9 builds yet
[18:31] <danilos> :(
[18:31] <chrisccoulson> we upload a build to natty as soon as they tag mozilla-central, but b9 isn't officially released yet
[18:31] <danilos> I guess I'll downgrade to 4.0b8 because I probably don't care about whatever's different
[18:33] <hrw> hello again
[18:40] <hrw> http://launchpadlibrarian.net/62183425/buildlog_ubuntu-lucid-amd64.armel-cross-toolchain-base_1.56_MANUALDEPWAIT.txt.gz shows that armel-cross-toolchain-base 1.56 failed to build for lucid due to missing dependencies. But in my lucid chroot which uses this PPA I do not have that problem: http://hrw.pastebin.com/JhNaHK3M shows that packages are available. can someone tell me what is wrong?
[18:51] <StevenK> Your lucid chroot is obviously i386
[18:51] <StevenK> *Everything* in your PPA failed to build on amd64
[18:52] <StevenK> Therefore it isn't available to that armel-cross-toolchain-base build
[18:52] <hrw> i386 built so far only arch=all packages.
[18:53] <hrw> and they are installed in my amd64 chroot.
[18:53] <hrw> I thought that arch/all packages in ppa will be available to i386 and amd64 builds
[18:54] <StevenK> Yes, still checking
[18:55] <hrw> all amd64 failures were planned as those packages generated only arch=all packages but had to have packaging altered minimally
[18:58] <StevenK> Right, so I think it won't check the second optional
[18:58] <StevenK> binutils-source (>= 2.21) | binutils-2.21-source
[18:58] <StevenK> Oh look, binutils-source 2.21 isn't available. Lalala
[18:59] <StevenK> hrw: sbuild is dumb. Reorder the Build-Depends for armel-cross-toolchain-base
[18:59] <hrw> ok, I will
[18:59] <hrw> thx
[19:19] <nhandler> Does anyone know why when I try to login to a site using OpenID (launchpad.net/~nhandler) it says that it tried to ask for confirmation for https://login.launchpad.net/id/dFWXJfF (which is not a valid OpenID identity URL) ?
[19:20] <geser> StevenK, hrw: see bug 594916
[21:06] <ovnicraft> hello yesterday tell me here about issues in queue translation knows if was fixed ?
[21:06] <ovnicraft> i still waiting my upload and download request
[21:06] <ovnicraft> 3 days
[21:08] <ovnicraft> and want to know if its posible filter the queue import by lang
[21:09] <ovnicraft> or maybe a webapi to consult
[22:45] <danilos> chrisccoulson, hi, do you mind if I ask you to fetch lp:~mozillateam/old-lp-translations/po2xpi and then push it to lp:~mozillateam/po2xpi/trunk (I am not in mozillateam so I can't do it, and I'd like you guys to have commit access to it more than me :)
[22:46] <chrisccoulson> danilos, yeah, sure. will do that in a bit
[22:46] <chrisccoulson> thanks
[22:46] <chrisccoulson> :)
[22:47] <danilos> chrisccoulson, thanks, I set up a basic project with some info just so it doesn't live on rosetta (now defunct and temporarily renamed to old-lp-translations) project
[22:47] <danilos> chrisccoulson, I've also pushed a branch with the fix for 4.0 XPIs
[22:47] <chrisccoulson> awesome, thanks!