[00:01] problem is i can't reproduce that: https://bugs.edge.launchpad.net/ubuntu/+source/seamonkey/+bug/190845/comments/4 [00:01] Launchpad bug 190845 in seamonkey "seamonkey has no Help > Report Problem in Help Menu" [Medium,Confirmed] [00:02] seems it's a broken perl-base [00:28] Fujitsu, bug 207461 [00:28] Launchpad bug 207461 in seamonkey "Please sponsor seamonkey 1.1.9" [Undecided,New] https://launchpad.net/bugs/207461 [00:29] i have the debdiff ready to be uploaded [00:29] you can already get the tarball [00:29] it will not change [00:29] fta: Grabbing it now. [00:54] Fujitsu, i'm done [00:54] enjoy [09:23] Fujitsu: fta: not sure if want to roll a sec update for stable xulrunners. in case we want mike has pushed http://people.debian.org/~glandium/xulrunner_1.8.0.15~pre080323b-0etch1_amd64.changes [09:23] asac: hi, from where could I fetch all Firefox translations? [09:24] carlos: from the ftp server :) [09:24] just kidding [09:24] let me look [09:24] asac: I'm going to do a full import/export test in our development server as requested by kiko to get all changes deployed with today's rollout [09:25] carlos: http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.0b3/linux-i686/xpi/ [09:25] asac: that means that I will provide you with a language pack tarball so you can do your part of the testing [09:25] asac: ok, thanks [09:25] thats all beta3 translations (for which the en-US.xpis is) [09:25] http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.0b4/linux-i686/xpi/ [09:25] thats beta 4 [09:26] what should I upload then? [09:26] but i think you need a new en-US.xpi too ... i think we should do that afterwards [09:26] carlos: beta 3 [09:26] do you have an updated en-US.xpi file? [09:26] ok [09:29] i have to produce them first. [10:23] test [10:23] good [10:29] asac: https://translations.staging.launchpad.net/ubuntu/hardy/+source/firefox-3.0/ [10:29] asac: I'm importing everything there [10:29] and xulrunner-1.9 ? [10:29] once I finish with the import process, I will be ready to produce the export [10:30] asac: is xulrunner in its own source package? [10:30] isn't it part of firefox-3.0 source package? [10:30] did you wipe your brain while on holiday ? [10:30] yes it is [10:30] I forgot it ;-) [10:30] we have two en-US.xpi ... but only one translation for all [10:30] so the idea is that you import the translation twice [10:30] I know that ;-) [10:30] ah [10:30] ok [10:31] but I thought both come from the same firefox-3.0 source package [10:31] yes ... the reason why we have two en-US.xpi is that we have two source packages [10:31] no [10:31] ok [10:31] let me move xulrunner then... [10:31] if that was the case we wouldn't need to the split [10:31] one source package will always provide exactly one en-US.xpi [10:31] carlos: the source package is xulrunner-1.9 [10:32] https://translations.staging.launchpad.net/ubuntu/hardy/+source/xulrunner-1.9/ [10:32] (xulrunner is outdated ... as is firefox) [10:32] right [10:32] carlos: has the import finished? [10:32] why are there so many untranslated strings? accesskeys? [10:32] the templates, yes, the translations, are still being imported [10:32] ah ok [10:33] was just confused by the count of German untranslated [10:33] it takes a while given the size of the files and given that is the first time we import them in that database [10:33] thats ok [10:34] asac: hmm German is already imported for both templates [10:34] 216 and 230 strings are untranslated [10:34] let me filter the untranslated [10:34] * asac using that webpage for the first time [10:35] en-US.xpi/en-US.jar!/locale/browser/appstrings.properties:2(malformedURI) [10:35] is not translated [10:35] lets see [10:35] (the suggestion is good though) [10:35] carlos: why are there good suggestions for everything? [10:35] Firefox can't establish a connection to the server at %S. [10:35] yeah, I just saw that problem [10:35] Firefox kann keine Verbindung zu dem Server unter %S aufbauen. [10:36] its a bug? [10:36] seems like we have a bug [10:36] yes [10:36] i mean those most likely come from the de.xpi [10:36] good [10:36] well not so good, but good that we notice [10:36] however, I guess is not a huge one, given that it still appears as a suggestion... [10:36] looks like its all .properties [10:36] not huge == not really an stopper to start using Launchpad [10:37] we will prepare a fix to get it cherry picked as soon as possible [10:37] well ... how will this be in the export? [10:37] (we could manually approve them of course i guess) [10:38] but maybe suggestions are already in the .po ? [10:38] approving 200+ strings for 20 translations is pretty much work i guess :) [10:38] no, that will be missed in the export [10:38] unless you have a script ;) [10:38] can we improve them efficiently somehow? [10:38] aeh approve i mean [10:39] so we can use the exports for real? [10:39] asac: using Ubuntu translators work ? :-P [10:39] ha ;) [10:39] let me talk with Jeroen about it [10:39] yeah [10:40] all properties missing might cause some UI pain :) [10:41] asac: the 'beauty' of language packs is that translators would fix it after release... [10:42] but yeah, I agree that is better if everything is workin since day 0 [10:42] well ... fixing is good, but fixing half of the UI is not so good .) [10:43] anyway ... a way to autoapprove the initial imports would be good [10:48] carlos: ok i talked to pitti. translations _after_ release have the same policies as package updates after the release. [10:48] (in theory) ... so lets better get all translations at least approved ;) [10:49] what do you mean by the same policies? [10:50] specifially this mean: you cannot change translations (except for typos). you can only add new translations ... and no new languages [10:50] carlos: SRU procedure: first upload to -proposed ... get testing/review ... then roll it to -updates [10:50] carlos: but indeed, updates are rolled once a month that way [10:51] so its somehow different [10:51] asac: well, is not 'change translations' but 'strings to translate' [10:51] you can change translations, that's the whole idea behind language packs [10:52] carlos: our policy is to not change the UI after release ... changing translations (except for typos) would change UI and thus should not qualify. [10:52] pitti said that there has been no precedence yet of radical translation changes (i think you say strings for that) [10:52] anyway ... doesn't matter in our case [10:53] asac: If that's true... we are not following that procedure in any released version, at least we are not forcing that [10:53] asac: and even in that case, is not translation changes, but actually fix untranslated strings [10:53] so it would still be considered as 'fixes' [10:55] carlos: sorry ... reconnect [10:55] 11:53 < carlos> asac: If that's true... we are not following that procedure in any released version, at least we are [10:55] not forcing that [10:55] 11:53 < asac> carlos: yes, he said there was no need to enforce that yet, because he didn't encounter any radical [10:55] changes so far [10:55] 11:53 < asac> just for your interest. [10:55] 11:54 < asac> carlos: just let me know how i can get all suggestions approved efficiently so we get a fully translated [10:55] firefox for release [10:55] asac: and even in that case, is not translation changes, but actually fix untranslated strings [10:55] so it would still be considered as 'fixes' [10:55] carlos: yes ... fixing untranslated strings is ok [10:56] but in our case it would be half of the UI [10:56] we should definitly find a way to get them translated before a release [10:56] I'm talking with jtv, maybe we could just fix it easily [10:56] ok thanks [10:56] asac_: anyway, we have a bit less than a month before release, right? [10:56] a proper patch should be landed next week [10:56] so it's not even an issue for release [10:57] i am fine with everything: 1. automated script that approves initial imports, 2. call for approving to translation owners [10:57] after that, I will do a full import again and everything should be 'fixed' [10:57] carlos: ok [10:57] don't know anything about the release procedures for launchpad [10:57] if its just a week, then its certainly fine :) [10:58] well, next launchpad release is post Hardy release [10:58] carlos: i initially understood that there was no way to fix this for hardy release [10:58] thanks for clarifying [10:58] however, we are able to do cherry picks for critical bugs [10:58] ok great. [10:58] and this qualifies for it [10:58] my concerns are suddently gone :-D [10:58] we can definitly start with that bug [10:59] asac_: there are two options, go ahead and open Firefox in Launchpad tomorrow and wait for a fix next week [10:59] (and maybe manually approve a few .properties so we can test if the .properties creation actually works [10:59] or wait until the fix landed [10:59] carlos: if thats the choice, go ahead [10:59] to publish firefox [10:59] asac_: I will need to confirm it with kiko, but I'm all for that first option [10:59] we could manually approve one language so we can see if the distro side works well [10:59] carlos: thanks. [10:59] let me know! [11:01] ok [11:08] carlos: ok, we have one more thing to clarify: auto import. [11:08] jtv: did a script to do the upload automatically [11:09] where does that script the en-US.xpi to be? [11:09] does it need any parameters (like source package name + path to xpi)? [11:09] so I guess is just a matter of using a cron job for it or give it to you so you can execute it manually when you want to [11:09] carlos: pitti wants to integrate that during package build [11:09] like what we do for the other translations [11:09] if we have a script thats fine. just need to know which parameters that script takes === asac_ is now known as asac [11:10] asac_: for the en-US.xpi, you don't need to do anything, we will get it from the package build automatically [11:10] asac: he just need to extract the xpi files like he does with .po and .pot files [11:10] carlos: i doubt that. at least i have to put it somewhere [11:10] asac: leave it in the source tree [11:10] after the build, there is a script that all packages execute [11:10] to extract .po and .pot files [11:11] it should be extended by pitti to take care of xpi files too [11:12] asac: it doesn't matter the path where you leave it, but don't change it or we will need to approve it manually with each upload [11:12] carlos: ok, but pitti doesn't need to use the upload script? [11:12] (e.g. you can change that?) [11:13] no, I misunderstood you [11:13] the script will be used to upload translations [11:13] which are not in your packages [11:13] and thus, not part of the build process [11:13] carlos: of course its not in the build process. its about the binary package mangler that - from what i understood - does the uploads [11:14] or is that in the build process for you as well? [11:14] carlos: anyway, i think once this is done, pitti should probably talk directly to you [11:14] asac: sorry, I call it part of the build process :-) [11:15] asac: sure, however, as I said, just tell him to extract .xpi files just like he extracts .po and .pot files [11:15] and that's all the work he needs to do [11:15] carlos: yes. did that [11:15] he appears to have understood :) [11:15] :-) [11:16] * asac still completely blind on how all this works ... e.g. how is the source package name found? [11:18] carlos: ok. i think all is clear now [11:18] now go back to work :) [11:19] asac: that's done from the buildd hook that provides us the files after the package build [11:19] it knows the package that is being built [11:19] so we get it from there [11:20] ah ok. [11:21] carlos: one more thing: there is not yet any other language than german on https://translations.staging.launchpad.net/ubuntu/hardy/+source/firefox-3.0 ... is the import still running? [11:22] yeah, the import is slow and I need to execute the script several times on that server (on production is a cron script) [11:23] ok [11:23] asac: oh, also, you are looking to the partial view [11:23] hmm [11:23] ah ... i hit "view translations & all languages" [11:23] click on 'View Template & All languages...' link [11:23] now i have more [11:23] :-) [11:24] what qualifies en_GB and de to appear on that other page? [11:24] carlos: you can edit SECONDS_TO_RUN in the cron script so it doesn't stop so often. [11:24] asac: your preferred languages settings IIRC [11:24] carlos: can we see why finnish has 2 more untranslated strings than the others (217 vs 215) ? [11:25] would be good to verify that its really a missing translation and not another bug [11:25] jt1: ok. [11:26] carlos: did you see any "Duplicate message ID" output while running the script? Those now only happen if the duplication is in the same file, but if there's a bug there, the messages would fail to be imported. === jt1 is now known as jtv [11:28] jtv: no, there is no such output [11:28] asac: I think I found the problem anyway, so it should be somehow easy to fix... [11:28] carlos: tell us! tell us! [11:28] which problem? [11:29] the ones that they are not approved? or the 217-215 (finnish vs. german) missing translations= [11:32] asac: btw, I 'lied' to you, the strings that are not translated now in launchpad but that were translated in xpi file will appear in the exported .po file [11:32] but with the #~ prefix [11:33] carlos: you have one example? [11:35] no, but once everything is imported, I will be able to show you it [11:36] ok. its not that important. i currently assume that we get those exported properly for final [11:36] for now we can test with a english-LANGUAGE mix :) [11:36] at least we get testing of the fallback mechanism that way :) [11:38] ;-) [12:09] * asac hospital [12:09] visit [15:48] asac : Hi, you asked me to recall you this : bug 194970 [15:48] Launchpad bug 194970 in firefox-3.0 "[Hardy] Incorrect .desktop files" [Medium,Fix committed] https://launchpad.net/bugs/194970 [15:48] asac : my branches are ready to merge with the main branches, and all linked to the bug report [15:50] saivann: if you don't see an ack from me in 1h ping me again. i am into something right now which might wipe all my memory :) [15:51] asac : Ok I will wait for your running process to terminate then :) [15:57] carlos: can we get the newly imported translations today? [15:57] asac: unfortunately we can't fix those contexts. [15:57] jtv: huh? [15:57] asac: yes, once all imports are done (still running....) [15:57] asac: the translation data is just structured too differently from the template. :-( [15:57] ah ok [15:57] asac: but as jtv tried to point, without the strings fixed [15:58] jtv: so this means that we have to manually approve the suggestions? [15:58] asac: right [15:58] i jsut find it interesting that its only .properties files [15:58] that reveal this bug [15:59] asac: is it!? I'm sure I saw dtd files as well. [15:59] jtv: i only saw .dtd for branding [15:59] which might be indeed missing [15:59] however, if there are .dtds then they are really rare ... which is why i thought this is a real bug [16:00] jtv: can you show me an example? [16:00] (for which the context is too different) [16:01] asac: the problem comes with locales [16:01] like German that has the same IDs twice in the .xpi file [16:01] asac: the problem in most cases seems to be that the template doesn't have the clashing message identifiers that the translation does. [16:01] which mixed with the fact that we don't read yet manifest files... it produces us to see conflicts when there shouldn't be any [16:01] asac: Because we have two "half templates" but complete translations. [16:02] Located in en-US.xpi/en-US.jar!/locale/browser/appstrings.properties:9(redirectLoop) [16:02] thats a translation with only suggestion [16:02] its in de.xpi/de.jar!/locale/browser/appstrings.properties [16:02] ok i understand about the clashing a bit [16:03] jtv: can we somehow automize the approval of initial imports? [16:03] asac: the German will have some clashes that you've basically removed from the template by splitting it into two. [16:03] ok. i see. [16:03] so we might even see the wrong translation as suggestions? [16:04] asac: yes, though the right ones should also be included. [16:04] asac: which is exactly why it's hard to automate this. [16:04] jtv: let me think. [16:05] jtv: can't you use the current context algorithm if the dtd and .properties are not in a jar [16:05] and otherwise use at least the full path in the jar as context? [16:05] that should give us enough context for most [16:05] if not all [16:06] asac: problem is, the translators have rearranged files. Do we know that this won't give us any bad matches? [16:07] jtv: i would say no ... but i have to chew a bit about that. [16:08] asac: you may have to look inside a lot of them to be sure. [16:08] jtv: i only need to look at the chrome.manifest files [16:09] jtv: but we have to live with this this week anyway. [16:09] so we have a few more days to figure this i guess [16:09] asac: guess so. And we're on a sprint next week. [16:11] [reed], why rc2 ? [16:39] [reed], b5~rc1 freezes and goes 100% cpu when i tell it to remember a password, reproduced 3 times out of 3 tries [16:40] sounds like a nss issue [17:20] damn, i can't commit to the ubufox branch [17:21] it's in ~ubuntu-core-dev [17:35] <[reed]> fta2: rc2 because of some plugin code [17:35] <[reed]> that regressed [17:42] ok, I'll have a look later [18:13] saivann: you should remember to close the LP bugs in changelog ;) [18:14] asac : Oh right.. sorry I did think about it, but forgot :), I can update my branch if you want [18:17] asac : Do you want me to update the branches, it would take few minutes [18:26] asac : I'm ready to push for firefox and thunderbird if you want it [18:37] saivann: the tbird branch is not based on the right branch [18:38] https://code.edge.launchpad.net/~mozillateam/thunderbird/thunderbird.dev [18:38] thats the right one [18:38] saivann: you did base it on the gutsy branch :) [18:39] asac : Oh... [18:40] asac : Ah right.. Sorry, that's very bad, I can fix this in some minutes if you want [18:42] would be good [18:42] i could do it manually, but would prefer to not :) [18:47] asac : https://code.edge.launchpad.net/~saivann/thunderbird/fix_desktop_file [18:52] asac : also updated firefox branch https://code.edge.launchpad.net/~saivann/firefox/fix_desktop_file [19:09] saivann: updated? [19:09] i already merged that ;) [19:09] (firefox) [19:09] let me try tbird [19:11] ah LP :) [19:13] asac : I don't see any branch for firefox 2.0 that has firefox.desktop fixed, firefox 3.0 should be already merged [19:13] no its not yet pushed :) [19:13] but i merged all locally already [19:14] anyway ... will see if i can get it [19:15] asac : Ok that's fine, thanks :) And sorry for my mistakes [19:17] asac : In case you also have time for this in the next days, I did not get translations from the mongolian translator for sunbird and lightning-extension. He answers my mail but I believe that his job won't be ready for Hardy [19:17] bug 174290 [19:17] Launchpad bug 174290 in sunbird-locales "[hardy] new upstream release 0.7" [Wishlist,In progress] https://launchpad.net/bugs/174290 [19:18] saivann: well ... the mistakes were more of cosmetic nature :) [19:18] except maybe for the tbird branch ... but the branch naming is not yet really consistant [19:19] so i see the fault on my side :) [19:19] saivann: don [19:19] t we jave 0.7? [19:19] man [19:19] don't we have 0.7 :( [19:19] typing is hard [19:19] ? [19:19] at least the merge was done on top of 0.7 here [19:20] asac : No, only 0.5 for mk. However, all other locales are ready for 0.7 [19:22] asac : The links to download my packages are on the bug report, it's exactly the same packages that you reviewed few months ago [19:22] saivann: https://edge.launchpad.net/ubuntu/+source/lightning-sunbird/0.7+nobinonly-0ubuntu2 [19:23] oh you say just the locales are not there yet? [19:24] asac : Yes, I only speak about the locales packages [19:27] asac : I just updated the links on the bug report because the lightning-extension-locales was dead. I don't know about your opinion, but I think that we should upload them to repositories and update them if we get locales for mongolian [19:28] saivann: mongolian is missing? [19:29] *sigh* hopefully this will all be history in hardy+1 :) [19:29] when we get our locales from launchpad [19:29] for all moz apps [19:29] asac : Yes, that's what I was speaking about, mongolian locale only exist in 0.5. You asked me few months ago to contact the translator to ask him to provide translations, the translator did not did the job yet. [19:29] did he reply? [19:30] saivann: http://releases.mozilla.org/pub/mozilla.org/calendar/sunbird/releases/0.7/langpacks/mk.xpi [19:30] that exists [19:31] asac : Yes, I cc you but you maybe missed the mail. He said that he would work on this but he did not specify a deadline, there is a lot of chances that the locales are not ready for Hardy [19:31] asac : Since when?? It did not exist recently! [19:31] well ... right now it exists :) ... better grab it before its gone ;) [19:31] asac : I agree :D [19:32] cool [19:32] let me know when thats integrated [19:32] and sorry for the delay on that [19:32] after all we will have a translated sunbird in final release. [19:32] ;) [19:33] asac : wait, I'm wrong, the iso code is not mk, but mn [19:33] mn is the missing one [19:33] oh [19:33] asac : Anyway it would not make sense, the mk locales is on the server since october :) [19:34] asac : Hehe, sorry to break the party :P [19:34] you never know ;) [19:34] ok fine. do you currently ship no package or an empty package? [19:34] for mn? [19:34] asac : Currently no package is build from the source package [19:35] asac : I suggest to upload and keep in touch with the mn translator. If he gives some translation, I will take care to include them very fast so we can update the package [19:35] asac : Curretly no *mn* package is built from the source package [19:38] saivann: you should build an empty one [19:38] look at the bottom of the mozilla-firefox-locales-all [19:39] package control file to get examples [19:40] asac : No problem, I can fix this. Is there any other things that should be fixed/added to my packages? The last time you reviewed them, you said that you would probably upload them as they are now [19:40] yeah. then there is probably no other issue :) [19:40] whats the bug id? [19:41] have it [19:41] bug 174290 [19:41] Launchpad bug 174290 in sunbird-locales "[hardy] new upstream release 0.7" [Wishlist,In progress] https://launchpad.net/bugs/174290 [19:42] asac : ( I know, the LP: field is missing here too ) :) [19:42] asac : I will add it now [19:42] cool [19:43] please create an empty package for non existing locales [19:43] thats all for now :) [19:43] asac : I will do it in the next hours and keep you updated about this [19:43] (given that the resulting translations work of course) [19:43] great [19:43] asac : Of course, all tested multiple times [19:44] asac : I did not get answers from the translator mailing list about ubufox translation but I got multiples additionnal translations, all in my ubufox branch. [19:48] good [19:49] asac : This will not be like rosetta, but still the translations looks good, and some translator reviewed their own translations and asked me to fix additionnal strings, so that sounds good [19:49] good [20:59] asac : sunbird-locales and lightning-extension-locales package are now fixed, bug 174290 [20:59] Launchpad bug 174290 in sunbird-locales "[hardy] new upstream release 0.7" [Wishlist,In progress] https://launchpad.net/bugs/174290 [20:59] asac : http://upload.leservicetechnique.com/bugs/lightning-extension-locales_0.7.tar.gz http://upload.leservicetechnique.com/bugs/sunbird-locales_0.7.tar.gz [21:00] asac : (empty debian binary package for mn locales are built and changelog have the (LP: ) field.) [21:01] * saivann out for ~60 minutes [21:18] saivann: the LP bug is still not named in sunbird-locales package [21:19] asac : Are you sure? " * new upstream release 0.7 (LP: #174290)" [21:22] thats in lightning yes [21:22] btw, you need to use an ubuntu address in Maintainer: field if you use 0ubuntuX version [21:22] asac : Also sunbird, I just looked and I re-uploaded the same package to my server [21:22] otherwise dpkg-source fails [21:22] either use MOTU or Mozillateam [21:22] you can set yourself as XSBC-Original-Maintainer if you want [21:23] i can fix the maintainer field if you want [21:24] evening... :) [21:24] ill use mozillateam in maintainer for now [21:24] Jazzva: hi [21:24] Hello, asac :)... [21:24] saivann: please ack that its ok for oyu [21:24] asac : You're right, I didn't know this when I built the package for the first time [21:24] thats ok [21:24] asac : Thank you [21:24] i can change it [21:24] Ok, you'll take care of the missing LP field also? [21:27] asac : Now that I packaged simdock with cdbs and all brother printer drivers package, I believe that I will be able to do better packages next time :) (If they are still needed in Intrepid of course) [21:28] asac : Concerning mozilla projects and rosetta, is there something I can do to help the process of switching all locales to rosetta? [21:31] saivann: no ... not in hardy [21:31] we will do it for xulrunner and firefox in hardy [21:31]