daf debonzi thanks a lot for your hard work recently 12:00 daf, if I have a variable inside a zpt called context/foo and lets supose it is a list. Is there a way to get in zpt the firt element without tal:repeate? 12:01 debonzi: I don't think so 12:02 debonzi: you have to resort to "python: context.foo[0] " 12:02 debonzi, Ok, thanks 12:02 debonzi: or otherwise add a method to the view class to get it 12:02 daf, Ill find a way.. thanks :) 12:03 de nada :) 12:03 daf: no problem. It's a pity that rosetta is not only yet :-( 12:08 === elmo_ [~james@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad carlos: why does the personal information form submit to ViewPOFile? 12:20 daf: does it? 12:20 let me check, I don't remember it now 12:21 daf: it submits to TranslatorDashboard... 12:21 I implemented the code there 12:22 about why TranslatorDashboard... the template was pointing there, I did not changed it 12:22 daf: ? 12:25 class ViewPOFile: 12:26 ... 12:26 def editSubmit(self): 12:26 ... 12:26 that's not the personal information 12:26 that's for the plural forms editor 12:26 elif "SAVE-PERSONAL" in self.request.form: 12:26 carlos, GO SLEEP 12:26 kiko: I did all pending tasks, let me end the conversation :-) 12:27 kiko: he needs to answer this question first :) 12:27 and I will go to sleep 12:27 daf: if you have it indide the viewpo 12:27 you have a broken file 12:28 I have it inside TranslatorDashboard 12:28 ah :) 12:28 I think I have a broken file, then 12:28 I've split up TranslatorDashboard into TranslatorDashboard and ViewPreferences, by the way 12:28 so it seems something weird has happened 12:29 daf: Sorry, back... use Foo.set(field1=value1, field2=value2) to clump UPDATEs into a single query, rather than one per field. 12:29 (I think I mention this in the SQLObjectGuide?) 12:29 daf: yes :-) 12:29 spiv: aha, thanks 12:29 do you want the original code? 12:29 I think I can work it out using a launchpad checkout 12:29 === carlos adds that to the bug report and promises kiko that goes to the bed ok 12:30 debonzi: You might be able to do context/foo/0 12:30 === spiv catches up on scrollback :) spiv: nope 12:31 spiv: it's equivalent to context.foo["0"] 12:31 Oh, right. 12:31 spiv: (sadly) 12:31 good. 12:31 ok, now it's time 12:33 good night!!! 12:33 daf: do we have a meeting tomorrow? 12:34 carlos: yes 12:34 12:00UTC? 12:34 yeah 12:34 ok 12:34 will you be able to make it? 12:35 sure 12:35 I'm willing to make an exception in this case 12:35 I'm not able to sleep more than 10 hours at the same time 12:35 ok :) 12:35 see you 12:35 === npmccallum [~npmccallu@69-162-252-7.ironoh.adelphia.net] has joined #launchpad sleeping sucks anyway. 12:42 haha! 12:43 To: daf@muse.19inch.net 12:43 Name: KDE 12:43 Description: 12:43 http://www.kde.org 12:43 (somebody requested that KDE be imported into Rosetta) 12:44 I suspect it was Dwayne :) 12:44 spiv: I think Carlos was really tired -- he mistook you for Stewart (https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=1973) 12:45 Hah. 12:46 he was up all of yesterday, all last night and all of today 12:46 as I say, sleep is overrated? 12:47 :) 12:48 === npmccallum [~npmccallu@69-162-252-7.ironoh.adelphia.net] has joined #launchpad === npmccallum [~npmccallu@69-162-252-7.ironoh.adelphia.net] has joined #launchpad === debonzi see u all === lifeless_ is now known as lifeless === npmccallum [~npmccallu@69-162-252-7.ironoh.adelphia.net] has joined #launchpad === npmccallum [~npmccallu@69-162-252-7.ironoh.adelphia.net] has joined #launchpad === npmccallum [~npmccallu@69-162-252-7.ironoh.adelphia.net] has joined #launchpad === stub [~zen@c211-28-34-252.sunsh1.vic.optusnet.com.au] has joined #launchpad === doko [doko@dsl-082-083-141-180.arcor-ip.net] has joined #launchpad === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad === limi [~limi@159.80-202-72.nextgentel.com] has joined #launchpad limi: morning! 11:41 === stub [~zen@dialup-33.53.194.203.acc03-dryb-mel.comindico.com.au] has joined #launchpad lulu: morning :) 11:52 saw that you felt in the deployment there are things you feel are outstanding. could you mail me the problems you found. If there are any further config changes we need done, I can get Upfront to do them. 11:56 spiv, elmo: any progress on getting the xml-rpc server running on rosetta.w.h.c ? 11:56 === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad morning 11:58 lulu: nothing is set up for deployment at all on the caching side 11:59 everything was set to not cache etc 11:59 yes - Upfront were not asked to do that. There was a decision taken that Squid would be used for cacheing for Launchpad tools and the webserver. In the meantime we are using Apache. Thanks for your help. 12:00 Plone still needs to be tweaked before deployment, nop matter what system you use 12:02 I think it is not sufficient to just turn on squid.  You need to do some configuration in plone to allow squid to cache certain things. 12:02 limi, lulu: Will you add the announcement mail into the news section of www.canonical.com? 12:06 some people asks me for a link to the announcement so they can publish it in their news website 12:06 carlos: will do 12:06 ok 12:07 they can link to the wiki, I think 12:07 daf: is the announcement there? 12:07 yes, I think so 12:07 ok 12:08 http://wiki.ubuntulinux.org/WartyWarthog_2fAnnouncementEmail 12:08 daf: thank you 12:08 I'm going to have breakfast now and back to work :-) 12:08 eek, more _2f madness 12:10 :) 12:11 === limi loves the irony of trying to use Wiki like a file system daf: thanks- no point in having it in 2 places - need to consolidate what's on the wiki and what will be on web. 12:14 lulu: yep 12:15 lulu: the website looks great, by the way -- congratulations :) 12:15 daf: thanks Daf - thanks to everyone's hard work. Needs a slick design and loads more content but that will come! :o) 12:19 daf: looking forward to having the Rosetta tan up there! 12:19 tab! 12:20 me too! 12:23 daf: howzit going? 12:28 we're feature-complete for the Alpha release 12:30 we'll do a review of the website today 12:30 then, once we've imported some data, we're done 12:31 daf: do you need some of Limi's magic on the UI? 12:38 lulu: yeah, we have some bugs filed about that 12:40 https://bugzilla.warthogs.hbd.com/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=limi&b 12:41 (apologies for the horrible URL) 12:41 daf: that's ok! 12:42 wow, that's crazy :) 12:45 === carlos checking the daf's patch basically #1949 and #1950 are pretty simple UI enhancements 12:52 #1934 is more of a comprehensive UI review 12:52 good start for today. My archive is broken 12:53 grrrrrr 12:53 carlos: any idea why scripts/poimpot.py instantiates TemplateImporter/POFileImporter with a None person? 01:02 daf: I fixed it yesterday before leaving 01:03 no idea why it was that way, but it's wrong and breaks the import 01:03 daf: you should have the patch at rocketfuel 01:03 oh, ok 01:04 I thought I was up to date 01:04 I fixed it locally 01:04 it's an easy change 01:04 It's me or chinstrap connection is slooooow 01:06 ? 01:06 I don't think it's you 01:07 I couldn't even connect 01:07 looks like they were discussing it on #canonical 01:07 it means I can't log in to rosetta 01:07 ok 01:09 daf: elmo can log in - just a little slow 01:14 daf: can you log in now? 01:14 === daf tries yep, it's working now 01:15 daf: good - thanks 01:15 daf: your patch works 01:23 we have only an UPDATE instead of 4 01:23 I thought it was 6 :) 01:23 but it's still slow (as you already know) 01:23 right, I feared as much :( 01:23 daf: well, It was yesterday when I detected it, I don't remember the exact number :-P 01:24 I was guessing it 01:24 daf: I don't think it's the database the bottleneck 01:25 as we know now :-) 01:25 I'm going to execute the import of the .po/.pot files now that lalo has fixed a bug I detected yesterday and at the same time I will try to profile the script 01:26 daf: or do you prefer to wait for the meeting in 30 minutes before start the profiling? 01:27 no, I don't think we need to wait 01:28 I think the bottleneck might still be in the database 01:28 perhaps the SELECTs we're executing are slow 01:28 I think Postgres has some tools for optimising queries 01:28 daf: the selects are too restrictive 01:29 well, forget that 01:29 if it's not an index 01:29 if it's not using an index it could be slow 01:29 is it using an index? 01:31 daf: btw... I'm executing the same queries by hand from psql and they are really fast 01:31 daf: no, that's why I told you that forget my words :-) 01:31 btw, the queries are fast, and we don't have lots of queries for every msgset 01:32 you think it is the code then? 01:33 yes 01:33 I suspect that 01:33 === carlos in profile mode daf: could you commit your patch? 01:34 althought it's still slow, I think it's better if we do it that way 01:34 I'm in the middle of something right now 01:38 feel free to apply and commit it yourself 01:38 ok 01:39 === ddaa [~david@nemesis.xlii.org] has joined #launchpad === debonzi [~debonzi@200.158.100.251] has joined #launchpad === cprov [~cprov@200.158.100.251] has joined #launchpad It is quite possible the database is a bottleneck - there has been no optimization done atm. If you identify columns that need indexes, let me know. 02:02 yes, I was wrong, top let's you see that postgres has more than a 80% of my CPU 02:05 lifeless, stub: I sent yesterday two changes to the DB schema, could you review them? 02:10 someone added patch-1-08 and conflicted with me :[ 02:14 I thought only the nazi was meant to add patches to the schema ? 02:14 lifeless: you are true 02:14 That was me, not letting go ;-) 02:14 hnmmm 02:14 lifeless: you are right :-P 02:14 === lifeless larts stub === lifeless larts stub === lifeless larts stub === lifeless larts stub === lifeless is done now The larting? I hope so 02:15 === stub bleeds :} 02:15 daf: meeting? 02:17 daf: or are we waiting for lalo? 02:17 carlos: I've no idea whether lalo will turn up 02:19 SteveA: around? 02:19 lifeless: is that URI syntax correct? 02:20 daf what? 02:20 ok, then if you want we could do the meeting. 02:20 lifeless: see my last email to the launchpad list 02:20 dunno. 02:20 daf: If you get it working, please make a canonical.lp.connect method - I don't want to remember the syntax if I can help it :-) 02:20 daf: The syntax is an SQLObject thing. 02:21 stub: well, dbhost is '' at the moment, so it will work 02:21 daf: not in production its not. 02:21 thats why dbhost is there. 02:21 lifeless: exactly 02:21 is //host/stuff 02:21 that's why I'm asking :) 02:21 spiv: is it postgres://host/dbname? 02:21 daf: Don't know :) 02:22 stub: how do we identify columns that need indexed? 02:22 * indexes 02:22 daf: the ones that are used often 02:24 to access data 02:24 how do we identify those? 02:25 looking at Postgres logs? 02:25 daf: no, looking at the queries 02:26 the WHERE clause 02:26 or looking at the logs if you prefer 02:26 the selectBy and things like that 02:26 from the sqlobjects 02:26 right 02:26 well, how often they're referred to in the code and how often they are queried in the database are two different things 02:27 daf: true, but the import script (for instance) is executed many times 02:28 sure 02:28 so we can improve those first, rosetta does not have problems (yet) 02:28 stub: a unique key is also an index right? 02:29 Yup 02:29 so we have already some "optimizations" 02:30 and it's still slow 02:30 daf: If a column appears in a WHERE clause (or in a SQLObject.select keyword argument) it probably needs an index 02:30 postgress://dbhost/dbname 02:31 lifeless: thanks 02:31 lifeless: where did you find it? 02:31 I figured it out when we setup launchpad in production on macquarie 02:32 daf: If you turn on postgresql logging of SQL commands and watch the file, it is often obvious what queries are chewing up the time 02:33 stub: ok, thanks -- we'll make a list and let you know 02:33 Oh..... indexes won't be used after you import a load of data until you ANALYZE. This might be the problem. 02:34 (cause PostgreSQL thinks the tables have only a few rows and it isn't worth using them - analyze updates these stats) 02:35 stub: yes, that could be the problem 02:35 stub: any way to improve it? 02:35 psql -d launchpad_test -c vacuum analyze 02:35 psql -d launchpad_test -c 'vacuum analyze' 02:35 stub: will it work while the database is being used (adding more rows?) 02:36 Yes 02:36 that will fix a part of the problem 02:36 Just slows things down a bit while it is running :-) 02:36 stub: any way to do it automatically or every X inserts? 02:37 because we are importing about 1000 or 2000 new rows 02:37 and we lookup that table with every addition 02:38 You generally run it from cron, or after you have made significant changes (% wise, not number of rows type things) 02:38 If you have 10,000 rows and add 1000, it won't make any difference. If you have 0 and add 1000, it will 02:38 stub: the field we use is a string and it's a unique key and should be indexed because the WHERE clause ask for it 02:39 so VACUUM ANALYZE will lead to an immediate improvement, or we need to define indexes and VACUUM ANALYZE? 02:39 If you know the query that is slow (eg. select foo from bar), run 'explain select foo from bar' in psql. You get some confusing output, but if you see Seq Scan it means it is slow (full table scan). 02:39 daf: the VACUUM sentence is to update the index 02:40 stub: ok 02:40 daf: In this case, probably immediate improvements since the indexes are likely already there (primary keys etc). 02:41 Please don't put any ANALYZE commands in your scripts, unless they are scripts that load sample data for development btw - prod will do this via cron 02:42 ok 02:42 stub: what happens if it's a big transaction with lots of inserts and queries against those previous inserts? 02:43 we are talking about 1500 INSERTS or UPDATES 02:45 carlos: On production, it probably won't make any difference unless you are changing a significant % of the rows in the table (say - 30%). 02:45 no, with every new import, the proportion will be smaller 02:46 So does the vacuum analyze speed things up in this case? 02:47 no, it's still slow 02:48 perhaps it helped 02:48 Do you know the query that is running slow? 02:48 but I'm still importing the same .po file with 1500 strings 02:48 stub: no 02:48 carlos: did you time it? 02:48 carlos: "time python poimport.py"... 02:49 daf: no, but I think it started about 45 minutes ago 02:49 ouch! 02:49 I thought we were talking seconds... not minutes! 02:49 I was thinking more along the lines of importing one file twice, once before the analyze, once after 02:50 stub: even hours :-) 02:50 === carlos laughts because don't want to cry something else is really screwy. Look at your postgresql log file to see what queries are being run 02:51 (preferably after turning that logging feature on...) 02:52 stub: I did and the queries executed by hand were fast 02:53 === carlos testing a small .po file real    0m44.759s 02:53 user    0m5.635s 02:53 sys     0m0.335s 02:53 a .po with 77 messages 02:54 Still worth a 'tail -f' on the log during a run - might just be qualtity of queries 02:54 and a reimport test of the same .po file: 02:56 real    1m26.643s 02:56 user    0m5.238s 02:56 sys     0m0.334s 02:56 stub: I will test the import of a .po file with only a msgid so I get all queries we do to import it 02:57 hmm 03:01 2004-09-16 15:01:09 [6093]  LOG:  unexpected EOF on client connection 03:01 is it normal after the script ends? 03:01 should we execute anything to close the connection? 03:01 conection.close() is nice 03:02 carlos: is this with poimport.py 03:03 ? 03:03 daf: ye 03:04 yes 03:04 hmm, that should be closing the transaction 03:04 === daf will be out for 10-15 minutes carlos: shall we have the meeting at 13:30? 03:07 daf: could we move it for later then? 03:07 daf: I will have lunch at that time 03:07 14:00? 03:07 I have a meeting with the Soyuz guys then 03:08 perhaps we could do both in parallel 03:08 daf: we could delay it more if you want 03:08 daf: I have work to do 03:09 so I'm not blocked for the meeting 03:09 ok 03:09 carlos: in future, can you attach big files to Bugzilla rather than pasting them? :) 03:09 ok 03:09 O:-) 03:09 ok, see you later :) 03:09 later 03:10 === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad daf: meeting in ten minutes ? 03:50 cprov: hi 03:50 cprov: might have to delay by 10 minutes or so 03:51 hi daf 03:51 hi Steve 03:52 so, some things are running really slowly in rosetta? 03:52 yes 03:53 specifically, the import 03:53 on my laptop, about 1.5 minutes to import a 512-message set PO file 03:53 the server is slow also 03:53 daf: no problem, I and debonzi are going to kiko's place, 10 minutes will be enough, see you later :), tks 03:54 we have an open bug about it, which has some discussion about the problem 03:54 cprov: ok 03:54 https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=1973 03:55 === kiko [~kiko@200-206-134-238.async.com.br] has joined #launchpad are we launching? 03:55 (or are we keeping radio silence) 03:56 kiko: I'm going to be a bit late 03:57 daf: you heartless man 03:58 daf, see u in some minutes 03:59 kiko, 10 min I'll be there 03:59 === debonzi running daf: 1.5 minutes for a 512-message set PO file is not too much time 04:11 we should improve it, yes, but it's not bad 04:11 for me it takes much more time 04:12 carlos: what is the usual range of sizes for a po file? 04:17 === cprov [~cprov@200-206-134-238.async.com.br] has joined #launchpad === debonzi [~debonzi@200-206-134-238.async.com.br] has joined #launchpad SteveA: I think we could say between 1500 - 2000 for non trivial applications 04:18 wait 04:19 SteveA: http://l10n-status.gnome.org/gnome-2.8/es/desktop/index.html 04:19 so 04:19 are we on? 04:19 seems like most gnome applications have less than 500 strings 04:20 but we have some with > 1500 and evolution with > 4000 04:20 if it's a text or trivial graphical application < 500 is the normal, a complex graphical application > 1500 04:21 daf: just say when you are ready ... 04:23 ok, back 04:23 ah, good. 04:24 carlos: but if you have 30 languages, then importing that one product takes 45 minutes 04:24 daf: that's perfect, I'm taking 45 minutes for only one .po file!!1 04:24 carlos: really?! 04:25 daf: I'm going to do real test with time now 04:25 but I think soi 04:25 carlos: which PO file? 04:25 gnome-applets 04:25 kiko: ready when you are 04:25 so 04:26 cprov: can you paste in some urls for daf to check out where we want to fit the data? 04:26 kiko: yep, one minute 04:26 daf: some open questions first. 04:26 daf: first, can you update https://rosetta... 04:27 daf: do translations for a certain package have a "lifecycle"? 04:27 daf: the DB too, please :) 04:27 daf: i.e. do they start as open and then go through a review and closing process? 04:27 kiko: they have a lifecycle 04:28 daf: what states? 04:28 kiko: https://www.warthogs.hbd.com/RosettaTranslationStates 04:28 daf: aha 04:29 okay. 04:30 daf: what do you think makes sense to display from the soyuz side of things, related to: 04:30 - source packages 04:30 - people 04:30 - distribution 04:31 - distribution release 04:31 (assume distro and distro release are just a group of packages) 04:31 hmm 04:33 well, for source packages, distributions and releases, you could show translation statistics for a language 04:34 you could show a pan-language translation statistic, but I don't think that's very useful 04:34 for a person, not sure 04:34 what sort of information about people does Soyuz currently show? 04:34 cprov: server should be up now 04:35 daf: can we get this sort of statistic ready-made from rosetta? 04:35 kiko: there are methods for statistics in th Rosetta interfaces 04:35 kiko: but you will need to map source packages to projects 04:35 daf: also, is it interesting to show "open" or "pending" translations for a specific source packages? 04:35 daf: how would that be doable? 04:35 what do you mean by "open" and "pending"? 04:36 daf: just have a look, at first, on ...soyuz/distros/ubuntu 04:36 I'm not sure -- perhaps something that indicates quickly that a certain package is "in need of" translations in certain languages. 04:36 daf: I'm thinking of something that will entice the soyuz user to hop into rosetta. 04:37 daf: It is the Distribution Main Page, we want to show, by Translation link (+translation) a set of translations informations . what do you think we can show ? 04:38 cprov: I see it 04:38 kiko: hmm 04:38 kiko: We can map SourcePackages to Products via the Packaging table, btw. 04:39 daf: so, do you have nice ideas ? 04:39 if you have information about what languages a user speaks, then you can give them status of that package in those languages 04:40 spiv: ah, that is interesting indeed. 04:40 spiv: is that an easy query? In reality I want to get from a sourcepackage to a project. 04:41 daf: neat idea. but the user doesn't specify anywhere what language he speaks 04:41 daf: given a source package, for instance, can we provide a direct link that says "translate this package (using rosetta)"? 04:42 or help translate this package. 04:42 kiko: we have it from rosetta 04:42 kiko: Rosetta stores information about a user's languages 04:42 kiko: and you can quite easily get that information 04:42 daf: ah, cool. but is the user the same user as a soyuz user? : 04:42 kiko: I think so: select Project.id from Project where Project.id = Product.project and Product.id = Packaging.product and Packaging.sourcepackage = %d; 04:42 daf: https://rosetta.warthogs.hbd.com/rosetta/prefs 04:43 kiko: yes 04:43 spiv: and with the project ID we can grab translation data, I assume? 04:43 daf: cool. jotted down. 04:43 Ask daf :) 04:43 hmm 04:43 kiko: https://rosetta.warthogs.hbd.com/rosetta/prefs 04:43 :-P 04:43 Although I suspect product is more useful to them (which is even simpler, if so) 04:44 daf should know about it already 04:44 carlos: yeah, I think I've seen this page before 04:44 :-) 04:44 daf: don't you feel we should have a centralized "user central"? 04:45 oops, looks like I broke the translator dashboard 04:45 kiko: yeah, that's something we should be aiming for 04:45 I am bothered by the given name and password fields here that will need to be done in soyuz as well. 04:45 daf: but no effort towards that has started. that's bad. 04:45 === spiv agrees kiko: that's a temporal solution so we can release the alpha 04:46 kiko: we work on the person table so it's the same for all launchpad 04:46 At the bare minimum, we should be aiming to re-use widgets between the soyuz/rosetta/malone people prefs pages, I think. 04:46 what happened to widgets? 04:46 spiv: we need to use the same user data pages, I'm pretty sure. though under those you could have app-specific preferences if it made sense. 04:47 kiko: it would be easy to link to Rosetta pages for products 04:47 spiv: I tend to think that languages are a "personal" configuration thing that isn't rosetta-specific. 04:47 kiko: I think we'll need app-specific prefs, but I think I'd prefer to re-use whole pages as well. 04:47 kiko: Right, not to mention generic stuff like name, passowrd and email address... 04:47 daf: okay, we'll start by doing that, I think then. 04:47 so, you have a sourcepackage 04:48 kiko: For products, the query I gave above gets even simpler. 04:48 you get the products for the sourcepackage 04:48 spiv: do you think you could get us some of this stuck in the database modules and then post a quick message to lp? 04:49 for each product, you link to /rosetta/projects/${product/project/name}/${product/name} 04:49 kiko: Ok. 04:49 roxor 04:49 daf: what about those statistics, can we obtain those by just providing a product or group of products, or do we need to do more bit-scrubbing? 04:50 kiko: well, it depends 04:50 you can easily get a statistic for a (product, language) combination 04:51 and you can easily make a pretty graph for it 04:51 ah, that's killer. 04:51 daf: any howto or example code? 04:51 it's knowing which language to use that's the problem 04:51 daf: and for a group of products, this becomes harder? 04:51 you *could* display all languages, but that would get very big 04:52 So, I'm expecting distributions will have a set of languages that they care about. 04:52 kiko: well, you could average the stats across groups of products 04:52 spiv: ah, but the database says nothing of that :) 04:52 spiv: could be, but what if that set is very big? 04:52 kiko: Right :) 04:52 daf: well, we can choose the user's preferred languages. 04:53 kiko: right 04:53 daf: Good point. 04:53 that's already a good compromise imo. 04:53 kiko: and fall back to a simple list if they haven't got any 04:53 okay. 04:53 daf: so we want example code that uses these stats. name a module! 04:53 And perhaps there will be multiple sets -- i.e. "we want 100% english, french, spanish, 95%+ for ...." 04:53 kiko: look at canonical.rosetta.interfaces 04:54 Which is something to figure out later, but just a thought to keep in mind :) 04:54 kiko: the *Count methods is what you want 04:54 daf: no callsites use this code today? 04:55 kiko: yes 04:55 kiko: I mean, some do 04:55 I mean, what does "callsites" mean? 04:56 === kiko provokes daf into violence! a callsite.. 04:56 a consumer perhaps? someone who uses that interface? 04:56 "caller"? 04:56 (callsite is pretty frequent in the mozilla circles but whatever). 04:57 ok, with you now 04:57 violence is never necessary :) 04:57 kiko: https://rosetta.warthogs.hbd.com/rosetta/projects/gnome/evolution/ 04:58 that page use them 04:58 carlos do you have a module name for that? 04:58 carlos: ah, you beat me to it 04:58 kiko: browser.py 04:58 aha. 04:58 (ooh, shiny!) 04:58 spiv: don't you think we can simply link to this page (using srcpkg product) ? 05:02 spiv: I mean, do it now, and after work on a "translation console". 05:03 cprov: Well, first I'll add a .product attribute to SoyuzSourcePackage :) 05:03 daf: 4 minutes to import a .pot file... perhaps I had a problem in other place (perhaps in my mind) or it has been improved... 05:03 cprov: But yes, it should be easy to link to. 05:04 cprov: And I'd be happy to link first, and develop a console/portlet/whatever-we-call-it incrementally from there :) 05:05 spiv: ok, it would be nice anyway, get some colorfull details sometimes :) 05:05 Yeah, everyone loves shiny colourful graphs :) 05:05 spiv, cprov, kiko: If you are playing with the login stuff, look at rosetta/scripts/createuser.py 05:06 spiv, I can make do .product attribute in SoyuzSourcePackage.. ok for you? 05:09 okay 05:10 this sounds like a good start 05:10 spiv, cprov, debonzi: you guys have anything else you are curious about? 05:10 kiko, thats ok for now 05:11 debonzi: I've already started. 05:11 spiv, no problem.. go already 05:11 kiko: not now, I think we can go ahead by email ... fitting ideas about portlet/console 05:12 kiko: Not at the moment.. I think we should probably bring up the people pages issue at the next launchpad meeting? 05:12 (and/or on the list?) 05:13 spiv: btw, have you seen the distro/team ? 05:13 spiv: I have add some confusing data to DB to explicity show the problems with person/team 05:13 spiv: definitely. 05:13 cprov: I haven't yet, I'll take a look. 05:14 spiv: ok 05:14 daf: carlos: spiv: thanks for the hints, lunch time 05:19 ok, later 05:19 === debonzi lunch so 05:27 I'll write up a summary tonight. 05:28 and give some prodding where it's necessary. :) 05:28 about 15 minutes to import one .po with about 1500 strings, it's too much time but I think we could work on it after the alpha release (and before the beta release) 05:35 daf: is it ok for you? 05:35 of course, we are talking about my laptop, in the server it will take less time 05:36 it'll have to do for now 05:38 I will change the bug about this to block the beta 05:41 daf: how is going #1969? 05:44 carlos: partly done 05:45 elmo: can you turn off HTTP auth on the other Rosetta server? 05:45 daf: do you need help? 05:45 I'm without any pending task blocking the alpha release 05:46 well, the initial import 05:46 but that's a computer work 05:46 I can do other things at the same time 05:46 ok, am I using a script to do an initial import? 05:46 I mean, am I using your import script, or just running the basic one? 05:46 it's a basic one, I will send you a .sql 05:47 ok 05:47 but it's still working 05:47 right, let me know when it's done 05:47 so It will take some time 05:47 sure 05:47 I wonder what happened to Steve 05:48 So we have #1907, #1908, #1930, #1932, #1934 and #1969 to be able to release the alpha, right? 05:48 carlos: I'm going to merge a patch to fix the translator dashboard 05:49 when it's in, it should ask you for authentication before you can use it 05:49 === carlos didn't know was broken :-) 05:49 ok 05:49 that list looks complete 05:49 I think I broke it yesterday 05:49 or this morning, rather :) 05:49 ok 05:49 does your patch close the 1930? 05:50 it does 05:51 but it's pretty ugly 05:51 perfect :-D 05:51 don't worry 05:51 if it works should be enough 05:51 yeah, we can make it prettier later 05:51 I will take care of #1932 (only gnome-panel and gnome-applets for the initial alpha release) 05:52 oh, cool 05:53 limi should work on 1934 (and we could move it to the beta, it's mainly UI improvements...) 05:53 and you said that #1969 is partially done, right? 05:53 yes 05:53 and finishing it should be really easy 05:53 so let's go to relese!!!! 05:54 :-P 05:54 just need to change pages.zcml 05:54 but I want the HTTP auth turned off first 05:54 the 1907 and 1908 are only reviews, so I suppose we could punt them to post alpha, right? 05:54 if necessary 05:55 if Steve can look at them before we release, that would be good 05:55 but if everything else is closed, then yes, we should release 05:56 limi should be back sometime today, I think 05:56 he was only going to the dentist 05:56 ok 05:57 "punt" is a good word 05:57 daf: I don't know the exact meaning, but it's the term we use with GNOME bugs 05:58 I get the idea 05:58 so I understand it :-) 05:58 but I don't know the translation, so... time to look for it :-D 05:58 punting is to do with boars 05:59 er, boats 05:59 hmm, I don't get the meaning in Spanish :-P 06:01 it's a type of boat 06:03 it's also a way of moving a boat using a pole 06:03 yes, it's more or less the meaning of the translation, but I don't see the meaning  :-P 06:04 well, when you're talking about bugs it means something completely different :) 06:07 :-) 06:08 shit, I was planning to attend the GNOME Summit but they moved it to October 06:36 :-( 06:36 where is it? 06:39 daf: GNOME Summit 3 06:40 October 9 - 11, 2004 06:40 from 10:00 AM to 6:00 PM 06:40 Stata Center 06:40 MIT 06:40 Cambridge, MA 06:40 I went last year 06:40 and I thought this year is also on november 06:41 :( 06:45 === debonzi [~debonzi@200.158.100.251] has joined #launchpad daf: merge confirmed 06:50 === cprov [~cprov@200.158.100.251] has joined #launchpad carlos: https://rosetta.ubuntulinux.org/++skin++Debug/rosetta/translator 06:56 oh, whoops, mea culpa 06:56 daf: :-) 06:57 spiv: ping ? 06:57 pong! 06:58 carlos: hmm, I can't seem to log in 06:58 should be working now 06:59 spiv: you inserted the product "firefox" reference on sampledata-soyuz.sql before I was created (by rosetta) 06:59 daf: where could I see the query that the login dialog does? 06:59 the db query 06:59 carlos: go to https://rosetta.ubuntulinux.org/rosetta, then click on the translator link 06:59 spiv: \s\I\it sorry 07:00 the db query? not sure 07:00 cprov: Oh, right. 07:00 daf: I mean the python code :-P 07:00 you'd need to ask Steve that 07:00 I was able to login 07:00 with my information 07:01 hrm 07:01 but I saw your preferences :-? 07:01 Probably in canonical.lp.placelessauth? 07:01 spiv: probably 07:01 let me check.. 07:01 carlos: ok, I can log in as daf, but not as the test user 07:01 spiv: complicated solution, I though, or place it on rosetta or move all rosetta inserts for product firefox to soyuz ? 07:02 === carlos misses the logout button... daf: it should work :-? 07:04 spiv: sorry, firefox product is a malone insert 07:05 cprov: Yeah, I was just noticing. 07:05 daf: Incoming parent... ;) 07:05 daf: it works for me 07:06 login: foo.bar@canonical.com 07:06 pass: test 07:06 I still see your personal data instead of the foo bar one 07:06 oh, I thought it was test@ 07:06 carlos: that's a bug in the preferences page 07:07 no, sorry O:-) 07:07 >:-) 07:07 we should get rid of the fake users where we can 07:07 cprov: The malone sampledata depends on soyuz sampledata; probably the easiest thing is to make a new sampledata-soyuz-extra.sql and add it to the Makefile..? 07:08 A little icky, but simple. 07:08 spiv: I just figured out that the Packaging INSERT should be on malone together others related to it (project, sourcepackagerelease and so on) 07:08 cprov: Ok, that's probably better than a new file. 07:08 spiv: yep 07:09 Even though strictly speaking it isn't sample data for Malone :) 07:09 Do you want to do that, or should I? 07:09 If you haven't already started, I'm happy to do it :) 07:09 spiv: even sourcepackagerelease ? you can do :) 07:09 daf: but I changed the fake user to be foo bar instead of you with the same patchset I added the emails 07:10 I was just going to move that one statement... oh, except it depends on soyuz data too :( 07:10 I think I'm leaning towards a new file, rather than dragging half the soyuz sample data into malone's.  One statement isn't too bad, but half the file is a bit excessive. 07:11 cprov: Either way, I'll do it :) 07:12 spiv: anyway the data are arranged in dependecy level in soyuz, if you insert in the correct place no reference will be missed, except "Sample Person" ( ohhh ?? ) 07:13 carlos: right, but we eventually want to get rid of fake_user() 07:13 daf: sure 07:13 carlos: hmm, what langauges should the product-index.pt page show if the user is not logged in? 07:14 daf: that's a good question 07:14 spiv: yep, I'm waiting your patch 07:14 carlos: I'll file a bug 07:15 we should hardcode a list or implement something like the widget that let's you navigate inside the strings to translate 07:15 so we don't show ever more than 5/8 languages 07:15 cprov: Nearly there :) 07:16 https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=1976 07:17 cprov: mirrored, merge request sent. 07:17 ok 07:18 https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=1977 07:19 I'll make 1976 beta-critical 07:20 spiv: thanks, I'm waiting the lazy arch star-merge :( 07:20 daf: makes sense 07:21 wow, the dependency graph has gotten messy 07:22 it should remove the old bugs or the graph will not be useful in some months 07:23 yeah 07:24 I asked it to generate a dependency graph for the .info imports and it went crazy :) 07:24 .info imports? 07:24 yeah, for Warty 07:24 URL? 07:24 don't bother 07:25 :-P 07:25 ok 07:25 it takes about 10 minutes to generate a very silly graph 07:25 with a few hundred bugs in it 07:25 it was very narrow 07:25 and very tall 07:25 and had a few small dots on it 07:25 malone will do it better :-P 07:25 I'm sure it will :-) 07:25 every .po file taks about 30 minutes to be imported now 07:25 I think I will give you a .sql with all ready to import gnome-panel's .po file in the server 07:26 (when I finish with gnome-applet) 07:26 it will be faster 07:26 === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has left #launchpad [] carlos: how are you doing the import? 07:54 for i in ls *.po; do time python /home/carlos/Work/rosetta/scripts/poimport.py -o 4 -f $i -p gnome -d gnome-applets -t main-2.8 -l echo$i |cut -f 1 -d '.'; done 07:54 do you have an estimate for how long it will take to finish? 07:55 I could tell you it 07:55 it's on en_CA now 07:56 am I user id 4? 07:56 hmm 07:56 perhaps tomorrow <- impossible to do it in my laptop... 07:56 I'm just wondering whether it might be faster for me to run that on the server 07:56 daf: yes I don't have the other launchpad data imported 07:57 daf: that's what I suggested some minutes ago 07:57 oh 07:57 right 07:57 I will wait until the en_CA.po is imported (it should finish soon) 07:58 and I will prepare a .sql file with my current database 07:58 so you don't need to start from scratch 07:59 daf: you need to "apt-get source gnome-panel gnome-applets" from warty 08:01 arg, no deb-src line in sources.list 08:01 can you give me a URL? 08:01 trying 08:05 but it's too slow 08:05 http://archive.ubuntu.com/ubuntu/pool/main/g/gnome-applets/ 08:05 http://archive.ubuntu.com/ubuntu/pool/main/g/gnome-panel/ 08:05 ok, the en_CA.po is imported 08:07 === carlos prepares a .sql export daf: you have the .sql at chinstrap's /home/carlos/launchpad.sql.gz 08:14 right, thanks 08:14 what does it include? 08:15 you don't need the schema 08:15 it will drop the database 08:15 and create and fill it 08:15 only rosetta data 08:15 ok 08:15 you can import the other .sql if you want 08:15 take care that perhaps it hardcode the launchpad_test name 08:15 I'm not sure 08:15 no, it's not hardcoded 08:16 you create a database and it will create all tables and data 08:16 when you have all ready, tell me it. 08:16 it includes already some gnome-applets .po files 08:17 carlos: ok, so I run "zcat launchpad.sql.gz" | psql -f -"? 08:33 no 08:33 "zcat launchpad.sql | psql launchpad_test" 08:33 you need the database created (if it's empty it's ok) 08:34 the -f - is not needed 08:34 hmmm 08:34 sorry put it 08:34 I'm not sure now.. 08:34 :) 08:35 psql::67148: ERROR:  must be owner of schema public 08:37 hmm 08:37 let me export it as INSERTS 08:37 perhaps it's more "portable" 08:37 ok 08:38 daf: could you try to execute it into the psql? 08:51 ALTER TABLE ONLY public.sourcepackage DROP CONSTRAINT "\$4"; 08:51 carlos: I'm having some trouble with my connection to the server 08:52 ok 08:52 daf: when you are able to test it, tell me it, so I can continue with the .sql export 08:55 ok 08:56 thanks 08:56 daf: should we ask lalo to join the channel so we can coordinate better the release? 08:56 I suspect it might just be easier to run the import on the server 08:56 carlos: I'll do that 08:57 daf: ok 08:57 daf: I will add then the products creation to the sampledata-rosetta-alpha.sql file 08:57 === npmccallum [~npmccallu@69-162-252-7.ironoh.adelphia.net] has joined #launchpad carlos: seems he can't use IRC at the moment 08:59 :-( 09:00 carlos: I think I need to take a break -- my head is starting to hurt 09:04 daf: ok 09:05 daf: see you later 09:05 carlos: I forgot to mention -- on the server, even though python is using 50% CPU and postgres 20%, importing the gnome-applets template takes 30s 09:06 daf: it took 4 minutes in my computer 09:07 it's the .po file what takes much more time 09:07 right, I'll time that when I run it 09:08 ok 09:08 daf: go away!!! 09:09 :-P 09:09 === limi [~limi@193.80.99.106] has joined #launchpad === limi [~limi@193.80.99.106] has left #launchpad [] daf: ping 10:49 pong 10:50 daf: any way to debug 10:50 the problem when you don't see any english text? 10:50 can you reproduce it? 10:50 yes 10:51 my local server 10:51 have you looked in the database? 10:51 with the gnome-applets have that problem 10:51 I don't know what should I look 10:51 ok, can you find the message IDs for the PO file? 10:51 funny:  Untranslated messages: -751 10:52 daf: one second 10:52 === carlos is getting a .po file exported first wow 10:53 the slow problem is also with po export... 10:53 daf: bug detected 10:56 launchpad_test=# SELECT * from pomsgid where id=1; 10:56 id | msgid 10:56 ----+-------- 10:56 1 | _About 10:56 (1 row) 10:56 launchpad_test=# SELECT * from pomsgid where id=2; 10:56 id | msgid 10:56 ----+------- 10:56 2 | 10:56 (1 row) 10:56 both are the msgid for the first msgset 10:57 what do you mean, both are?! 10:58 there are two message ID sightings? 10:58 that we have two rows where we should have only one 10:58 yes 10:58 with the same plural form? 10:58 launchpad_test=# SELECT * from pomsgidsighting where pomsgset=1; 10:59 id | pomsgset | pomsgid |       datefirstseen        |        datelastseen    | inlastrevision | pluralform 10:59 ----+----------+---------+----------------------------+----------------------------+----------------+------------ 10:59 1 |        1 |       1 | 2004-09-16 16:56:34.057532 | 2004-09-16 16:56:34.057532 | f              |          0 10:59 2 |        1 |       2 | 2004-09-16 16:56:34.110388 | 2004-09-16 16:56:34.110388 | t              |          1 10:59 (2 rows) 10:59 that's not a plural form 10:59 ok, but the second sighting has pluralform=1 10:59 msgid "_About" 10:59 msgstr "" 10:59 and the the first one also has inlastrevision=f 10:59 and the first one is the correct one 11:00 weeeeeird 11:00 the second is "" 11:00 bug! bug!! 11:00 big bug 11:00 I am also getting weird problems with authentication 11:00 daf: seems like finally it works here 11:00 I don't see you information anymore, I see the default one 11:01 I mean the foo bar one 11:01 I made some changes locally which breaks it somehow 11:01 I can't work out how 11:01 hmm but my server did not asked me for a login... 11:01 is that normal? 11:01 ok, you don't have it activated in all places yet 11:01 it should ask you for a login, I think 11:02 yes, but only from the translator dashboard 11:02 oh right, yes 11:02 the preferences one isn't activated 11:02 I'll do that now 11:03 and now I see your information as mine, so it's still broken 11:03 ok 11:03 daf: do you need help to debug your problem? 11:03 for now, I will just undo the change 11:03 I've emailed Steve 11:03 ok, I will look at the bug with the import 11:03 seems lalo is on Jabber 11:04 but I will file it first 11:04 right 11:04 daf: not now 11:04 he looks online to me 11:04 not for me :-? 11:04 restarting 11:04 still missing 11:04 yes, I see lalo now 11:05 hmm, Jabber being weird again 11:05 I will file the bug report 11:05 daf: #1978 11:13 thanks 11:14 hmm 11:23 daf: do you read anything from me? 11:23 yes 11:23 at jabber? 11:23 yes 11:23 I don't get my text back 11:24 now 11:24 wow 11:24 lag 11:24 lag 11:24 lag 11:24 for one minute 11:24 l 11:24 a 11:24 g 11:24