=== braiam is now known as cap_nemo === cap_nemo is now known as braiam === braiam is now known as cap_nemo === cap_nemo is now known as braiam [08:20] good morning all [08:36] good morning [08:42] morning andrejz :) [08:43] i have a couple of questions about import queue but will ask you in about half an hour [08:43] need to do something work related before that [08:51] ok, cool, yeah, ask whenever :) [09:00] Good morning [09:10] Good morning RawChid [09:12] Hi andrejz [09:13] How is the "template priority thing" going? [09:20] @RawChid: I am already done with it :) About 10 packages with new names appeared in oneiric, so i have to only sort those out [09:22] Now i am working on the import queue [09:24] i started on friday and there were 219 items in need review and now tehre are only 102 left [09:25] \o/ [09:25] Good work :) [09:26] some of them are there normally (they linger there for a day or two before they get imported) so actual value is lower [09:31] dpm, I see launchpadmanager in the code. But that file/class doesn't exist. Is it something you didn't copied yet, or is it to be built? [09:34] I don't know where to find it, already looked in some other branches [09:43] RawChid, err, sorry, I moved it to another folder and it seems I forgot to commit the change :( - anyway, it's online now, you can find it by pulling the latest commit, thanks for the heads up! :) [09:48] Ahh great. I discovered something about the search tool [09:49] When searching in dutch translations, it didn't worked before I login (into Gnome) once with a user using Dutch [09:49] So the lang pakcs getting copied or something [09:55] RawChid, I'm not sure what you mean by "login into GNOME". The only thing the tool does is to search the translations in the .mo files in /usr/share/locale-langpack [09:56] oh, I think I see what you mean now... [09:56] the tool, when called with no arguments, [09:56] detects the language of your session [09:56] and searches for that language [09:57] but you can specify a language explicitly in the command line [09:57] Yes, I know [09:58] Already checked it. But I suspect the /usr/share/locale* dirs getting filled the first time a user logs in [10:08] RawChid, I'm not sure what you mean there. Those dirs are filled when the system installs (or when someone installs a new language) [10:12] Hmm, I had it last weekend on another system. Can't re-check it right now. Maybe I did something wrong. For the time being not very interesting [10:14] ok :) [10:25] ok dpm, now it's my turn to bug you :) [10:26] my first question is how to find out if a package is in main [10:26] for example tehre are many postgresql related packages with need review status [11:06] dpm, are you thre? [13:06] hi andrejz, I'm here now [13:07] all templates that end up in the imports queue are in main [13:07] as we're only allowing main imports for now [13:08] ok, cool [13:08] next question ;) [13:08] however, sometimes templates get imported because they were in main, [13:08] and then they get demoted to universe [13:08] in those cases we need a way to see if they are in main/universe [13:08] does it make sense import things such as gcc and postgresql, which are going to be used exclusively by more tehcnical users? [13:10] andrejz, I think it still makes sense, although I'd definitely give them a low priority. Generally, I haven't accepted gcc translations because they seem to come from different packages, and until now I haven't investigated what the right one is [13:10] ok will do [13:10] and now for the third question, what to do with packages which include version number [13:10] for example [13:10] gnome session [13:10] in 11.04 there is gnome-session-2.0 [13:11] but now there is gnome-session-3.0 in import queue [13:11] how to use existing translations in such a case? [13:11] andrejz, I guess we'll have to do the same thing as in evolution [13:11] the same goes for gcc (gcc-4.5, gcc-4.6) and such [13:11] @dpm: but there is important difference [13:12] in that case we need to rename gnome-session-3.0 to gnome-session-2.0, which is incorrect [13:12] evolution-3.0 > evolution is ok, gnome-session-3.0 > gnome-session-2.0 in not, IMO [13:13] do you undestrand my dilemma, dpm? [13:14] andrejz, good point. In that case, what do you think if we first rename 'gnome-session-2.0' in all distros to 'gnome-session', and then in oneiric only 'gnome-session-2.0' to 'gnome-session'? [13:15] let me check out what the name was in other releases and if there ever was a 'gnome-session' template or 'gnome-session-1.0'... [13:15] ok [13:37] andrejz, ok, I've changed 'gnome-session-2.0' to 'gnome-session' to all releases from dapper to oneiric. Do you want to finish this off and approve the new 'gnome-session-3.0' template (and renaming it to 'gnome-session' before you press the button)? [13:37] sure [13:38] i should import the first file if there are several of the same files, correct? [13:45] andrejz, correct. If you import the first one, the auto-approver script in Launchpad will take care of the next ones in the queue [13:46] cool [13:46] for gcc both 4.5 and 4.6 are in the import queue [13:47] probably only the newer version should be imported === henninge is now known as henninge-lunch [13:52] dpm i suggest renaming of postgresql packages [13:52] since now they include version number [13:53] so if i want to do that i should only change natty, correct? [13:53] andrejz, ok, let me have a look first... [14:02] andrejz, if we change template names, we should make sure we do it for all releases, since otherwise message sharing won't work (I know, it's a pain :( ). The other thing is that we should probably use version numbers in the case we're shipping two different versions of the software, which looking at https://translations.launchpad.net/ubuntu/oneiric/+templates seems to be the case in oneiric (postgresql 8.4 and 9.0). Let me check if the 8.4 templa [14:02] tes should remain active or not... [14:03] ok, it seems that postgresql-8.4 has been demoted to universe, so I'll disable the 8.4 templates first of all [14:04] (in oneiric) [14:06] actually, there is no need to rename templates in previous versions [14:06] for this particular package [14:08] but if we want to transfer the translations form previous versions names need to be the same [14:08] since the 8.4 translations come from a postgresql-8.4 source package and the 9.0 ones from another. So since the templates are in different source packages translations won't be shared anyway. So the only thing we need to to is to disable all the 8.4 templates in oneiric and approve the 9.0 ones without a version number in the name (as you've already corectly been doing) [14:09] ok [14:09] i also added postgresql in front of the name to make it clearer to translator where they come from [14:12] andrejz, yeah, that's a really good idea :) [14:12] most of the packages start with pg- prefix but not all [14:18] ok, all 8.4 packages are disabled in oneiric now [14:20] andrejz, I've noticed xkeyboard-config is on the queue, although it had been approved before. After investigating it, I saw that in the admin page the path of the oneiric template in LP was different than the one in the import queue entry. The one in the import queue entry is the correct one (upstream changed it), so that one you can just approve as it is in the queue (after approving it, the existing template in LP will be updated with the new pa [14:20] th value) [14:20] brb [14:24] ok [14:32] andrejz, the localechooser and choosemirror templates are part of debian-installer (they are just generated during the build), so they should be blocked rather than accepted. In general, all templares named templates.pot should be looked at first, because they can generally be blocked [14:33] do typos in different languages (not the english source) should be filed as bugs? [14:33] ok, i looked at them and they made sense so i accepted them, wasn't aware they are a part of debian installer [14:34] @serfus: sure. even better get in contact with your translation team directly and tell them about the bug === henninge-lunch is now known as henninge [14:34] list of reported bugs is not actively checked by all teams [14:34] but they get notified when we assign the bugs to them [14:37] i think that typos should be dealt within a team, [14:37] what i mean is that i see no reason for a bug [14:38] @sefus: we enourage everyone to just report bugs directly on the mailing list or our chat room, especially if it's something small since it causes extra overhead for everyone if it's reported in launchpad [14:38] serfus, we report them as bugs so that teams can be notified. Now if the reporter knows how to contact each translation team and does that, then there is no need to report the bug. But most people don't know/won't directly contact the translations teams [14:39] at dpm just wrote what i was about to add :) [14:39] ;) [14:39] roger that [14:42] :) [14:42] andrejz, for gcc we should keep the version number in the template name, since we're shipping both gcc-4.6 and gcc-4.5 [14:43] is it possible to share translations between them in that case? [14:46] i have disabled debian installer templates [14:46] andrejz, no, translations are only shared between the same source package and template. In this case they come from two different source packages. To be clear, though, message sharing will still happen for e.g. gcc-4.5 in all previous (and future) Ubuntu releases, and gcc-4.6 for all (future) releases [14:46] ok i get it [14:47] cool, yeah, thanks for disabling them. As I say, the 'templates.pot' templates are always suspect, and in most cases they should be blocked [14:49] there is something else in gcc apart from the need to rename it, and this is why I hadn't approved the templates yet: there are several imports with the same template but a different path, and I'm not sure which one the right one is. Let me see if I can find out more... [14:55] ok, i will wait with gcc until i get more information [15:09] andrejz, [15:09] hi doko, I'm looking at the translations imports queue in LP, and there are a couple of .pot templates coming from gcc which I'm not sure what to do with. They are the same template but come from different paths. My guess is that I should approve one (the one from src/) and block the other one (the one from src-spu/), could you please confim? They're these: [15:09] src/libcpp/po/cpplib.pot [15:09] src-spu/libcpp/po/cpplib.pot [15:09] dpm: ignore the src-spu one (only built on powerpc) [15:09] doko, ok, cool, thanks [15:10] so we can block the src-spu templates in gcc and approve the others [15:10] ok, will do [15:10] andrejz, awesome, thanks [15:12] dpm how long does it take for the script to import all newer templates with the same name [15:13] dpm, can't find xkeyboard config, have you approved it before me? [15:14] andrejz, the same time it takes for it to import other new templates ~20 minutes if there is no load, ~1 day as a rule of thumb. xkeyboard-config: yeah, I had it opened on a tab, so I thought I might as well approve it :) [15:15] i am naming gcc packages something like -"gcc-4.6-cpplib" [15:16] dpm if i understand gcc 4.4. can be safely disabled in 11.10? [15:19] andrejz, apparently gcc-4.4 is still in main, so we need to keep it. As per renaming, in this particular case I'd not rename the templates, since it'd be too much work for too little gain (you'd need to rename all source packages and templates for all releases, and it's not an important template). I'd just stick to the naming we've been following until now (and I'm hoping it was consistent :) [15:20] so just cpplib as suggested? [15:21] let me think for a second... [15:22] so we've got these 3 templates: cpplib [15:22] gcc [15:22] libstdcpp [15:22] for gcc-4.4, gcc-4.5 and gcc-4.6 [15:23] so perhaps we should just attach the -4.4, -4.5 or -4.6 suffix to each of them [15:24] ok, sure [15:25] andrejz, if you're doing it, please do that only for the gcc-4.5 and gcc-4.6 source packages, which are new (had not been approved before). For gcc-4.4 we'll need to rename the templates in all series to make message sharing work, but [15:26] I don't want to do this manually, so let me see if I can extend the tool to set priorities to do renames as well [15:26] i would like to fix Bug #789567 as the fix is very easy, but i have no idea where to start... one of you knows and have some time to spare? ;-) [15:26] Launchpad bug 789567 in sessioninstaller (Ubuntu) (and 1 other project) "Typo string 38 (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/789567 [15:26] and let's leave the gcc-4.4 template name untouched, so that we remember they need to be changed [15:26] ok dpm [15:27] serfus, great :) So here's how you can start, if you're familiar with bzr. Run 'bzr branch sessioninstaller' [15:28] err, sorry, typo: [15:28] bzr branch lp:sessioninstaller [15:29] ya :) [15:29] okay got it [15:29] (first time a bzr-ed this way) [15:30] dpm, what would the translation file look like? [15:37] serfus, the source file reference in launchpad tells you where in the source code this string comes from, but you can also search it manually. So now you can change directory to the sessioninstaller branch you've just checked out and run: [15:37] grep -R -n --exclude *.po "opened and" * [15:38] the output of this command will tell you in which file the original string comes from [15:38] so it seems it's the sessioninstaller/core.py file, on line 761, right? [15:38] everything clear so far? [15:40] right [15:40] but there is no such file or directory [15:41] there is on my system, I've just checked out the branch and followed the steps as I was explaining [15:42] serfus, are you inside the sessioninstaller directory? [15:42] you can open it in nautilus [15:42] yes [15:42] i am in nautilus [15:42] inside there should be another 'sessioninstaller' directory [15:42] could be i just don't see it [15:43] serfus, what exactly can't you see? [15:43] oh i see [15:43] my bad [15:43] :) [15:43] ok, no worries :) have you found the core.py file where the string comes from? [15:44] yes [15:44] if so, you can now open it with an editor, go to line 761 and fix the string [15:44] let me know when you're done [15:44] only about 50 templates imported before 2011-05-29 remaining :) [15:45] dpm, done [15:45] andrejz, wow, cool :) [15:46] dpm i will bug you again tommorow, i wan't to get it at least down to 30 before translations open [15:46] serfus, ok, now save the file in the editor and go back to the command line, where you should type 'bzr status' and then let me know what the output of the command line is [15:46] andrejz, excellent :) [15:47] modified: [15:47] sessioninstaller/core.py [15:49] arr dpm i have to leave now... thanks allot, i'll be back later and will continue [15:49] excellent, now you can just commit your changes: [15:51] bzr commit --fixes=lp:789567 [15:51] Then you push the branch into LP: [15:52] bzr push lp:~serfus/sessioninstaller/bug-789567 [15:54] then go to your https://code.launchpad.net/~serfus code page in LP, find the branch, click on it, and then click on the "Propose for merging" button [15:54] This will submit your branch to the sessioninstaller developers to merge your changes. [15:55] Additionally, you should go to bug 789567, click on "Link a related branch" and add the link to the branch [15:55] Launchpad bug 789567 in sessioninstaller (Ubuntu) (and 1 other project) "Typo string 38 (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/789567 [15:55] And that should be it :)