[01:44] <debonzi> lifeless, hi.. is the PQM blocked again?
[01:47] <debonzi> elmo, ping
[01:47] <debonzi> elmo_, ping
[01:57] <elmo_> I'll check
[01:57] <elmo_> but you guys should get some sleep
[01:58] <elmo_> yeah, lalo broke it
[02:05] <debonzi> elmo_, first I need to get some cprov stuf :)
[02:05] <debonzi> elmo_, and you guy, before sleep, please fix it :)
[02:09] <elmo_> I can't dude, my connection keeps dieing
[02:09] <elmo_> is yours working?
[02:10] <debonzi> elmo_, yes.. seems to be
[02:10] <debonzi> elmo_, Im using the cable on
[02:10] <debonzi> one
[02:22] <lifeless> I'll fix it
[04:12] <lifeless> hey
[04:12] <lifeless> I don't have time to be futzing with launchpad at the moment.
[04:12] <lifeless> is there stuff from Marks edict that is needed for the canonical.arch subdir or canonical.soyuz subdir ?
[04:30] <cprov> lifeless: btw, RAW runs with some hacks on imports but I still missing doc/guides
[04:30] <lifeless> thanks
[04:31] <cprov> lifeless: you're welcome
[06:12] <stub> lifeless: canonica.soyuz probably. Don't know about canonical.arch.
[06:13] <stub> I'm not actually sure what problem he is trying to solve, so I'm not sure what exactly needs to be done.
[06:14] <lifeless> I've got the monthly ACS meeting tonight.
[06:15] <lifeless> oh bah. ignore that, I'll just ring SteveA tonight.
[10:36] <cprov> stub: morning, I need your suggestion about how to integrate a full DB dump with real packages imported in 
[10:38] <stub> I don't think we can do that with the new system Mark setup for the sample data - it will have to all be rekeyed somehow or tossed (at least those tables being used in production - this may not be a problem as it is probably better sample data)
[10:39] <cprov> stub: I've already done something on this direction, have you seen the current.sql ?
[10:40] <stub> Yes, but I don't know what changes you are talking about
[10:42] <cprov> stub: we have now the Ubuntu universe imported to soyuz context using a nice script called gina
[10:43] <cprov> stub: soyuz context = source/bin/person/etc
[10:43] <stub> Yes - but did you suck that in from the production database dump?
[10:44] <stub> I'm not sure what your original question was about now.
[10:46] <cprov> stub: just to clarify, I removed all package info from the original DB, then insert everithing from the real universe, now I have a dump of this table (filled)
[10:47] <kiko> right
[10:47] <kiko> we have a 130 (or so) MB file
[10:48] <stub> If you removed all package info from he original DB, then wouldn't you have destroyed the Malone sample data while you are at it?
[10:48] <cprov> stub: the question is : How to integrate it as our Production DB or whatever ?
[10:48] <stub> So we want to install this on Emperor?
[10:48] <cprov> stub: nop, I leave you  mozilla(dummy) sourcepackage there :)
[10:49] <kiko> stub, it still needs some validation, but maybe
[10:49] <kiko> the question is how to populate new databases -- do we use this data?
[10:49] <stub> To install it on emperor, I would need to run a script that inserts records into the database but doesn't remove anything.
[10:49] <kiko> because it's a *lot* of data
[10:50] <stub> Oh... so this is for the dev database, not production?
[10:50] <kiko> that's doable, we can isolate copy froms there
[10:50] <kiko> still for devs
[10:50] <kiko> when it goes into production, we'll have gina running in a cronjob
[10:50] <kiko> it can incrementally process packages
[10:50] <stub> ok. I think I'm on the correct page now :-)
[10:51] <stub> I wouldn't want that entire database installed by default, so running 'make' in database/schema should just import current.sql.
[10:51] <stub> Running 'make full' could import the large dataset.
[10:51] <kiko> but I still want to make sure it's all good data
[10:51] <kiko> or maybe make soyuz-extra
[10:51] <stub> Does that sound usable?
[10:52] <kiko> given that "full" is a bit ungeneric
[10:52] <kiko> err
[10:52] <kiko> generic
[10:52] <cprov> oopps ... we already have soyuz-extra :)
[10:52] <kiko> I don't know, should full bring more data?
[10:52] <kiko> is our target having more blobs of rosetta/malone data?
[10:52] <kiko> stub, I have 13,000 packages for you :)
[10:53] <stub> The 'full' target can have dependancies on 'full-soyuz' etc.
[10:53] <kiko> come to think of it
[10:53] <cprov> yeah, now the current.sql is enough for all the other apps( it's suposed to be) the real imported data is like a alpha DB 
[10:53] <stub> so 'make full-soyuz' would just import the extra soyuz data and 'make full' extra soyuz data and perhaps some rosetta stuff.
[10:54] <stub> Hmm... actually...
[10:55] <stub> It would be nice if this wasn't stored in the launchpad--devel branch so people don't have to download it.
[10:55] <cprov> stub: look nice to me ... but we still having 130 Mb files (:-0)
[10:56] <cprov> stub: off course : |
[10:57] <stub> So it is a seperate package you can enable in your configs/canonical.com/launchpad/development file that doen't involve modifying launchpad--devel at all ?
[10:58] <cprov> stub: or simple download it from some of canonical machines (KISS)
[10:58] <cprov> stub: anyway ... do you think it would be possible ? any suggestion ?
[11:00] <stub> I would create a new branch designed to be installed into the top level launchpad directory containing a simple makefile and the output of pg_dump
[11:01] <stub> As long as the pg_dump format is the default (text), diffs should make updates efficient.
[11:01] <cprov> stub: yes 
[11:01] <kiko> yeah
[11:01] <kiko> we're discussing it with mark & steve
[11:13] <SteveA> hi stub
[11:13] <SteveA> are you available for a phone call with mark in a bit?
[11:13] <stub> Sure
[11:13] <SteveA> great
[11:13] <SteveA> also...
[11:13] <stub> How bit a bit? (Me was thinking of dinner)
[11:14] <SteveA> tomorrow morning, we'll be moving interfaces, page templates, and database classes around
[11:14] <SteveA> and consolidating them into one place
[11:14] <SteveA> want us to just move the malone ones?
[11:14] <SteveA> if so, can you get all your changes checked in by then?
[11:14] <stub> Morning UTC you mean?
[11:15] <SteveA> yes
[11:15] <SteveA> starting 10amutc
[11:15] <SteveA> stub: how about you go get dinner, and call mark on his cellphone when you're done?
[11:16] <stub> I'll be done in 30 mins
[11:16] <SteveA> oh, not 10am utc
[11:16] <SteveA> 10am BST
[11:16] <SteveA> that's 9am UTC I think
[11:16] <SteveA> ok, I'll tell mark 30 mins
[11:27] <carlos> morning
[11:36] <debonzi> carlos, morning
[11:37] <carlos> debonzi: hey, yesterday I saw that we born the same day :-P
[11:37] <carlos> not sure if the same year :-)
[11:37] <debonzi> realy.. ? Nice.. :)
[11:37] <kiko> debonzi, carlos: spiv and I were born on the same date as well
[11:37] <carlos> 11st November
[11:38] <carlos> hmm or it's 11th ?
[11:39] <dilys> New bug 2057 for Launchpad/Rosetta: Hilight interpolations in c-format messages
[11:39] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2057
[11:39] <carlos> daf: ?
[11:40] <carlos> hmm, that bug will be interesting
[11:41] <kiko> 11th
[11:53] <daf> carlos: yeah, interesting :)
[11:54] <carlos> daf: I'm still thinking about using the same "special chars" for the new line and space for the entry field
[11:56] <daf> carlos: it's an interesting idea
[11:56] <daf> carlos: would that work through JavaScript?
[11:56] <carlos> phone, sorry
[11:58] <carlos> daf: Yes, I suppose it should be done with JavaScript
[11:58] <dilys> New bug 2058 for Launchpad/Rosetta: Show template completeness statistics on translation page
[11:58] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2058
[11:58] <carlos> should I file a bug report for limi about it?
[11:59] <kiko> hey!
[11:59] <kiko> who got this dilys thing?
[12:00] <daf> carlos: file a bug on it, but don't assign it to anyone yet
[12:00] <kiko> daf! 
[12:00] <kiko> daf rox0r
[12:00] <daf> :)
[12:00] <dilys> New bug 2059 for Launchpad/Database: Better constraints on 'name' columns
[12:00] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2059
[12:01] <kiko> dude
[12:01] <kiko> I need to file some bugs now
[12:01] <kiko> to get the title of top bugspammer
[12:01] <kiko> npmccallum, be sure to ping me when you're in 
[12:04] <carlos> kiko, our personal irc flooder :-P
[12:05] <dilys> Bug 2045 resolved: Debug skin & authentication don't mix
[12:05] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2045
[12:21] <dilys> New bug 2060 for Launchpad/Rosetta: Glyphs should be changed also in the edition fields
[12:21] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2060
[12:23] <dilys> Bug 1968 resolved: SQLObject needs to use the DEFAULT value for a column as defined in the database
[12:23] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=1968
[12:26] <sabdfl> stub: around?
[12:26] <stub> sabdfl: Sure
[12:27] <sabdfl> stub: will call shortly, higher bandwidth :-)
[12:29] <kiko> stub, you da man
[12:32] <stub> Closing all those bugs except for yours ;)
[12:32] <carlos> daf: the upload link is still there in the alpha server...
[12:33] <carlos> https://rosetta.shuttleworthfoundation.org/projects/gnome/gnome-panel/main-2.8/upload
[12:40] <daf> kiko: http://www.joelonsoftware.com/articles/Unicode.html
[12:40] <daf> carlos: is it linked from anywhere?
[12:41] <carlos> daf: yes
[12:41] <carlos> https://rosetta.shuttleworthfoundation.org/projects/gnome/gnome-panel/main-2.8
[12:42] <daf> hmm
[12:42] <kiko> oh no
[12:42] <kiko> I'm going to have to *understand* unicode now :-(
[12:43] <daf> carlos: at least it doesn't do anything :)
[12:43] <carlos> daf: :-P
[12:43] <kiko> stub, I'll reassign it
[12:48] <carlos> daf: seems like gettext wraps the lines before we do it:
[12:48] <carlos> msgid ""
[12:48] <carlos> -"Failed to locate a program for configuring the date and time. Perhaps none "
[12:48] <carlos> -"is installed?"
[12:48] <carlos> +"Failed to locate a program for configuring the date and time. Perhaps none is
[12:48] <carlos> "
[12:48] <carlos> +"installed?"
[12:49] <daf> hmmm
[12:49] <carlos> msgid ""
[12:49] <carlos> -"The use of this key was deprecated in GNOME 2.6 in favour of the 'format' "
[12:49] <carlos> -"key. The schema is retained for compatibility with older versions."
[12:49] <carlos> +"The use of this key was deprecated in GNOME 2.6 in favour of the 'format' key. "
[12:49] <carlos> +"The schema is retained for compatibility with older versions."
[12:49] <daf> perhaps the default is off by one?
[12:49] <daf> 79 instead of 80, or whatever it is?
[12:50] <carlos> Yes, it seems to be that
[12:50] <carlos> I'm going to change it
[12:50] <daf> thanks
[12:53] <carlos> daf: I think it's 78
[12:53] <carlos> 78 + 2 for the char quotes
[12:53] <carlos> 78 + 2 for the quotes
[12:54] <kiko> stub, dude
[12:54] <kiko> psql:comments.sql:99: ERROR:  relation "scrapedproject" does not exist
[12:54] <kiko> stub, are those droppings yours? :)
[12:55] <stub> Yes
[12:55] <stub> spiv: Did you get my comments on the scrapedproject yesterday?
[12:55] <stub> kiko: Leave the dropping please
[12:56] <kiko> okay but it's starting to smell
[12:56] <cprov> stub: aha, don't worry he is maniac
[12:56] <kiko> who? lalo?
[12:56] <cprov> kiko: hehe
[12:56] <stub> lalo is starting to smell????
[12:56] <kiko> NO
[12:56] <kiko> your droppings
[12:59] <kiko> stub, ping me when you get cprov's request merged, I want it so gina can breathe easier
[12:59] <stub> the gpg one? doing that now.
[01:00] <daf> carlos: so, what are you working on right now?
[01:01] <carlos> at this moment I'm reviewing the exported .po files from our alpha server
[01:02] <carlos> when I finish, I will retake the bug #1970
[01:04] <kiko> thanks stub
[01:04] <kiko> it is such a pleasure working with you man
[01:05] <kiko> you just get all of our crap moving
[01:05] <kiko> uhm, I didn't mean it to come out that way
[01:05] <daf> carlos: I think #2058 would be a pretty quick fix
[01:06] <carlos> I will look at it then before #1970
[01:07] <daf> also, could you comment on #2042?
[01:07] <carlos> we should priorize all our bugs for the beta release...
[01:09] <carlos> daf: done, I will answer lalo's question as soon as I finish the po export review
[01:11] <daf> carlos: thanks
[01:13] <stub> cprov: What is the value for a 'D' algorithm GPG key? I havn't got the constants in my copy of lp/dbschema.py
[01:14] <elmo_> DSA/ElGamal
[01:14] <cprov> stub: I didn't commit yet, but for instance they are attached on bug 2055
[01:15] <stub> ta
[01:17] <cprov> stub: btw, we need also lower() constraint in Person.name, could you arrange it too ?
[01:17] <stub> Sure
[01:17] <stub> cprov: It is already there actually
[01:18] <cprov> stub: yep, I just saw, sorrry 
[01:23] <carlos> daf: the devel server is down
[01:23] <daf>     NameError: name 'UTC_NOW' is not defined                                                                                                                              
[01:24] <daf> ^^^ that's why
[01:24] <carlos> daf: stub did some changes about it, perhaps you need latest version from rocketfuel
[01:24] <daf> nope
[01:24] <daf> latest RF crashes with that error
[01:25] <carlos> daf: then, look at the import section
[01:25] <daf> lib/canonical/database/constants.py", line 9:
[01:25] <daf>     nowUTC = UTC_NOW                                                                                                                                                      
[01:26] <stub> Me fix
[01:32] <carlos> daf: could you do a check for me, please?
[01:33] <daf> carlos: sure
[01:33] <carlos> daf: get a evolution .po file from your rosetta server
[01:33] <daf> for which language?
[01:34] <carlos> and check that msgid_plural is not always the msgid value
[01:34] <carlos> daf: es.po 
[01:34] <carlos> but I suppose it should be the same always
[01:34] <daf> ??
[01:34] <daf> msgid != msgid_plural
[01:34] <stub> kiko, daf: patches with PQM
[01:34] <carlos> the alpha server does it correctly, but my local server has that bug
[01:34] <kiko> stub, you da rockstar
[01:35] <carlos> daf: I kwonot they are different 
[01:35] <carlos>  /s/kwonot/know/
[01:35] <daf> :)
[01:35] <daf> what do you mean by "should be the same always"?
[01:35] <carlos> if you have the bug, they should be always the same
[01:35] <carlos> :-)
[01:35] <carlos> msgid "%d contact"
[01:35] <carlos> msgid_plural "%d contact"
[01:35] <carlos> msgstr[0]  "%d contacto"
[01:35] <carlos> msgstr[1]  "%d contactos"
[01:36] <carlos> well, that one is not a good example
[01:37] <carlos> because it's also broken in the alpha server
[01:37] <carlos> so perhaps it's aproblem with sample data
[01:37] <carlos> but this one has the bug:
[01:37] <carlos> msgid ""
[01:37] <carlos> "Opening %d contact will open %d new window as well.\n"
[01:37] <carlos> "Do you really want to display this contact?"
[01:37] <carlos> msgid_plural ""
[01:37] <carlos> "Opening %d contacts will open %d new windows as well.\n"
[01:37] <carlos> "Do you really want to display all of these contacts?"
[01:37] <carlos> that's the correct value
[01:37] <carlos> and I get:
[01:37] <carlos> msgid ""
[01:37] <carlos> "Opening %d contact will open %d new window as well.\n"
[01:37] <carlos> "Do you really want to display this contact?"
[01:37] <carlos> msgid_plural ""
[01:37] <carlos> "Opening %d contact will open %d new window as well.\n"
[01:37] <carlos> "Do you really want to display this contact?"
[01:37] <daf> hmmmmmmmmm
[01:38] <daf> bug! bug!
[01:38] <kiko> spammer!
[01:38] <carlos> daf: could you confirm it? 
[01:38] <daf> kiko: er, the pot calling the kettle black?
[01:38] <carlos> kiko: :-D
[01:39] <daf> carlos: should I star-merge from RF before I check?
[01:39] <carlos> daf: no, that way we could try to detect where is the problem
[01:39] <carlos> check it now
[01:39] <daf> ok
[01:39] <carlos> if it works correctly, star-merge and if it fails we could look only to the new patchsets you got from rocketfuel
[01:43] <daf> are any of our tests failing? :)
[01:43] <carlos> daf: the functional tests should fail...
[01:43] <carlos> let me check
[01:44] <carlos> daf: yes, it fails
[01:45] <dilys> New bug 2061 for Launchpad/Launchpad: SQLObject better Error Handler engine 
[01:45] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2061
[01:48] <daf> carlos: ah, good
[01:51] <daf> carlos: it seems to work here
[01:51] <daf> msgid ""
[01:51] <daf> "Opening %d contact will open %d new window as well.\n"
[01:51] <daf> "Do you really want to display this contact?"
[01:51] <daf> msgid_plural ""
[01:51] <daf> "Opening %d contacts will open %d new windows as well.\n"
[01:51] <daf> "Do you really want to display all of these contacts?"
[01:51] <daf> a regression!
[01:52] <carlos> daf: is it ok for you to merge now with rocketfuel or is it a problem now?
[01:52] <carlos> for you
[01:54] <daf> I can do that now
[01:55] <carlos> ok, thanks
[02:00] <carlos> daf: are you getting the msgsets ordered by sequence?: https://rosetta.shuttleworthfoundation.org/projects/gnome/evolution/evolution-2.0/translate
[02:04] <dilys> New bug 2062 for Launchpad/Soyuz: dbschema doesn't tell you it wants multiple lines when it dies
[02:04] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2062
[02:05] <lalo> hello
[02:05] <carlos> lalo: hey!, hello
[02:05] <kiko> LALO LALO LALO
[02:10] <lalo> almost two days without internet! that's torture
[02:10] <lalo> someone should pass a law that cutting a person's internet is against human rights
[02:11] <limi> it's actually a human right in some european country, can't remember which :)
[02:12] <lalo> I must move, then.
[02:15] <daf> carlos: yeah
[02:15] <daf> carlos: I'm probably sorting them the wrong way :)
[02:16] <carlos> daf: I think you are not sorting them
[02:16] <carlos> :-P
[02:16] <daf> hmm
[02:16] <daf> I'm check
[02:16] <daf> I'll check
[02:16] <carlos> ok
[02:16] <carlos> daf: Will we have a meeting now or could I go to have lunch?
[02:17] <daf> let's have a quick meeting
[02:17] <lalo> yay meeting
[02:17] <daf> orderBy='sequence'
[02:18] <carlos> ok
[02:18] <carlos> daf: then something is not working as it should :-P
[02:19] <daf> hmm, belay that
[02:20] <daf> I think you're right; it's not sorted
[02:20] <daf> I was looking at the wrong thing
[02:20] <daf>             return RosettaPOMessageSet.select(query)[key] 
[02:27] <carlos> daf: could we start the meeting?
[02:27] <daf> sure
[02:28] <daf> ok, what have we been working on today?
[02:29] <carlos> I was reviewing the export code
[02:30] <carlos> and detected two bugs, one fixed, another one is in being debugged (the one I asked you)
[02:30] <daf> and you found a bug?
[02:30] <daf> which was the fixed one?
[02:30] <carlos> the line wrap
[02:30] <daf> ah, right
[02:31] <carlos> I fixed also the functional test because It did not saw the wrap bug
[02:31] <daf> nice!
[02:32] <daf> lalo: what have you been up to? :)
[02:33] <lalo> statistics
[02:33] <lalo> I progressed as far as I could without net connection... then I was forced to take 1.5 days off :-)
[02:33] <lalo> yesterday night I committed what I had
[02:34] <daf> groovy
[02:34] <daf> I saw your comment on the bug -- can you and Carlos liaise on working out the rosettaUpdates part?
[02:35] <carlos> My next task in my TODO list is answer lalo's question
[02:35] <lalo> great
[02:36] <lalo> I realized rosettaCount is actually two categories of msgsets
[02:36] <lalo> 1. msgsets that we have translations for in Rosetta, and were not in the PO
[02:36] <lalo> 2. msgsets that had no translation in the PO and have some in Rosetta
[02:36] <lalo> 1 is what I'm counting now, but I don't know how to find 2 with sql
[02:37] <carlos> lalo: origin
[02:37] <carlos> but we could talk about it after the meeting
[02:37] <lalo> yes
[02:38] <daf> sure
[02:38] <lalo> what more? are we done?
[02:38] <lalo> daf: do you want me to move stuff around after we're done with stats?
[02:38] <daf> I've been doing various stuff related to the alpha
[02:39] <lalo> I suppose you answered my email, but I haven't got to it yet
[02:39] <daf> I just took on 2057
[02:40] <daf> lalo: I think the people here in London are thinking of doing all the moving, but I'm not sure
[02:40] <daf> SteveA: is that correct?
[02:40] <daf> lalo: at any rate, can you confirm with Steve before you start?
[02:41] <daf> lalo: I assume you've seen his mail to the list
[02:41] <lalo> if it's in the last 12h, not yet
[02:42] <SteveA> we will do all the moving here
[02:42] <daf> SteveA: great
[02:42] <daf> lalo: do you have enough tasks to keep you occupied?
[02:42] <SteveA> between 0900 and 1200 UTC tomorrow
[02:42] <lalo> daf: yes
[02:43] <lalo> well
[02:43] <carlos> daf: any chance to get a list of bugs sorted by priority?
[02:43] <lalo> since I'm at a later timezone, I can make myself responsible for fixing anything that happens to break after the moving
[02:43] <lalo> although I don't expect anything to break :-)
[02:44] <daf> carlos: why not?
[02:45] <carlos> daf: so?
[02:45] <carlos> :-P
[02:45] <daf> carlos: well, we can assign priorities to bugs, can't we? :)
[02:45] <carlos> yes
[02:46] <carlos> My question is more: "Who should do that?" than "How could we do that?"
[02:48] <daf> I see
[02:48] <daf> well, don't be afraid to assign priorities to bugs
[02:48] <daf> I'll try and use the priority field more myself
[02:49] <carlos> ok
[02:50] <daf> limi: I know your priority is Malone at the moment, but have you had a chance to look at any of the Rosetta bugs assigned to you?
[02:51] <limi> daf: almost finished the autofocus
[02:51] <daf> limi: cool!
[02:53] <carlos> daf: anything else?
[02:53] <daf> limi: I suspect #1950 would be easy to fix -- I could do it, but when I tried it looked really ugly
[02:53] <daf> (https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=1950)
[02:53] <daf> carlos: no, I think we're done
[02:54] <daf> oh, by the way:
[02:54] <daf> I'll be travelling back to Wales this afternoon, so I'll be offline for a few hours
[02:54] <carlos> ok
[02:54] <carlos> see you later, lunch time
[02:55] <daf> later
[03:02] <limi> daf: looking...
[03:03] <daf> :)
[03:03] <dilys> New bug 2063 for Launchpad/Launchpad: prettify "logged in as" thingy
[03:03] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2063
[03:04] <limi> daf: yes, should be easy - let me see if I can fit it in today or early monday
[03:04] <daf> spiv: so, apparently you can get information on bugs as XML from Bugzilla very easily, but not XML notifications
[03:04] <daf> limi: great!
[03:16] <lalo> ooh, I must be really good at python
[03:18] <kiko> either that or you've had too much mescaline
[03:19] <lalo> I seem to have been granted access to Guido's time machine
[03:22] <lulu> limi: Mark is also able to do the upload for you, when you're ready Limi.
[03:22] <lalo> daf: do you want to get a say in my priorities, or can I just pick my own way trough it?
[03:23] <daf> lalo: time machine?
[03:23] <daf> lalo: I'd like to have a say
[03:23] <lalo> you don't know Guido's time machine? man, you're not properly educated in Python lore yet :-)
[03:23] <limi> lulu: well, it's more involved than an upload
[03:24] <lalo> it's an old in-joke in the Python community for when a bug is fixed in a commit a few days before it's reported
[03:24] <limi> we need to link in the style sheet in Lurker template etc
[03:24] <lalo> (or feature request)
[03:24] <lalo> Guido took that to a form of art - he sometimes does that with *releases*
[03:26] <daf> haha :)
[03:26] <lalo> my tasks for today are: (a) #1975 (make script able to update statistics en masse); (b) move my transaction hack from poimport.py to sqlbase.py; (c) work on the rosettaCount query with Carlos
[03:26] <lalo> (c) will be done, I suppose, whenever Carlos can :-)
[03:27] <daf> are there bugs open for each of those tasks?
[03:30] <lalo> (a) and (c) but not (b)
[03:30] <lalo> although if I made a bug for (b) I could probably make a half-dozen bugs depend on it
[03:31] <lalo> [off: and access to the Time Machine is supposedly reserved for the greatest gurus, so when someone demonstrates having access for the first time, it's usually occasion for commemoration ;-)] 
[03:31] <daf> well, if it has a short lifespan, it's probably not worth doing the dependency stuff
[03:31] <daf> [what was the bug in this case? :)] 
[03:32] <lalo> [#2042, but I didn't fix the bug itself, the time-machine usage was on a technical detail of how to fix it] 
[03:33] <lalo> actually doing the transaction thing would *fix* a few bugs straight away, I believe - at least one
[03:33] <daf> which one?
[03:34] <lalo> looking
[03:35] <lalo> #1986. In fact, I could "turn" #1986 into the bug for this task, with a simple rename.
[03:35] <lalo> I suppose I'll do that - saying #1986 depends on having transactions is being too anal; I think #1986 *is*, pragmatically, the lack of transactions.
[03:36] <lalo> I need more clothes, brb
[03:37] <daf> that seems reasonable to me
[03:38] <daf> or, as you say, make a new bug and make #1986 depend on it
[03:38] <lalo> I'll rename #1986
[03:40] <dilys> New bug 2064 for Launchpad/Soyuz: Import "chosen ones" as default users with chosen usernames
[03:40] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2064
[03:42] <daf> lalo: liberate those transactions! :)
[03:42] <lalo> dude. apps which mess with the window stacking should be taken out and shot. :-/
[03:42] <daf> which app are you thinking of?
[03:44] <lalo> I hate it when I'm typing something, then Firefox pops up because it finished loading an app, and my Enter keypress event ends up going to the button labeled "Delete all your important files, send your credit card number to a very visible public location, and mail a death thread to George W. Bush"
[03:47] <lalo> not that I have a credit card, but you get my point.
[03:50] <daf> indeed
[03:51] <carlos> hmmm
[03:51] <carlos> we have a "problem"
[03:51] <carlos> there is no way to calculate the rosettaCount number
[03:51] <carlos> with our current database
[03:52] <lalo> I suspected that :-P
[03:52] <lalo> not even, maybe, with a subtransaction?
[03:52] <carlos> because the sequence will be != 0 if the .po file has a null translation but has the msgid
[03:52] <carlos> hmmm, perhaps we could play with dates
[03:52] <lalo> (09:46:32) lalo: I realized rosettaCount is actually two categories of msgsets
[03:52] <lalo> (09:46:47) lalo: 1. msgsets that we have translations for in Rosetta, and were not in the PO
[03:52] <lalo> (09:47:03) lalo: 2. msgsets that had no translation in the PO and have some in Rosetta
[03:52] <lalo> (09:47:16) lalo: 1 is what I'm counting now, but I don't know how to find 2 with sql
[03:54] <carlos> lalo: I saw that
[03:54] <lalo> I know
[03:54] <lalo> I'm repeating for reference, as it's relevant
[03:54] <carlos> the problem is that we don't have a way to know if that translation was already reimported from the database
[03:54] <lalo> I'll go make mate, think on, I'll brb
[03:54] <carlos> hmm
[03:55] <carlos> perhaps a datefirstseen == datelastactive could do the work
[03:55] <carlos> until we split the msgid and the translations
[03:55] <carlos> if we add a translation from rosetta they will be the same
[03:55] <carlos> if we export a .po and import it again
[03:56] <carlos> the dates will be different
[03:56] <carlos> yes, it should do the work
[03:58] <daf> perhaps this should be documented on the wiki under RosettaTranslationStates
[03:58] <carlos> ok
[03:58] <carlos> let me check that I'm right and if it works, we add it :-)
[03:59] <lalo> carlos: what if we only imported the .po once?
[04:00] <lalo> (and added no translations trough the web)
[04:00] <lalo> then datefirstseen == datelastactive
[04:00] <carlos> lalo: that's the origin field :-)
[04:00] <carlos> origin = 1 --> comes from a .po file
[04:00] <carlos> origin = 2 --> comes from Rosetta
[04:00] <carlos> that field will not change
[04:00] <lalo> aha
[04:01] <carlos> so datefirstseen == datelastactive && origin == 2
[04:01] <lalo> hmm
[04:01] <carlos> well, and inlastrevision=TRUE
[04:01] <lalo> daf: when I was writing the code, I detected a conceptual problem
[04:02] <lalo> it boils down to - when you import a file, you can be either updating from revision control, or submitting translations as an user
[04:02] <lalo> do we handle that?
[04:02] <daf> when we do an import, we currently assume it's from revision control
[04:02] <lalo> because the only place where this makes a difference is statistics
[04:02] <lalo> yes
[04:03] <lalo> so for now we keep assuming that?  If we do (which is fine given alpha/beta constraints), we should say so in the upload page
[04:03] <lalo> (I don't know if we already do, I'm just dumping my brain)
[04:03] <daf> the upload page doesn't do anything
[04:04] <daf> (yet)
[04:04] <lalo> ah, well. Then that's ok :-P
[04:04] <lalo> back to the problem at hand
[04:04] <daf> when the upload page is implemented (there's a bug open and a partial implementation in a branch), that assumption will need to change
[04:05] <lalo> hmm. that would require substantial changes to pofile_adapters.  Would you like me to do that change before I leave?
[04:05] <carlos> daf: I think we decided to handle the web upload as SCM uploads after talking about it with Mark
[04:05] <lalo> (like, probably, next week)
[04:06] <daf> carlos: for now, yes
[04:06] <daf> carlos: but in future we should be able to do other uploads too
[04:06] <carlos> ok
[04:06] <carlos> like xml-rpc ? :-P
[04:06] <daf> no, I mean uploads of translator owrk
[04:06] <daf> owrk
[04:07] <daf> work
[04:07] <daf> grr
[04:07] <daf> I mean not-from-SCM translations
[04:07] <carlos> daf: if we develop an application that connect to rosetta using xml-rpc (like gtranslator or kbabel..), that's other origin
[04:08] <daf> oh, right, yeah
[04:12] <lalo> ok, set 2 is something like: WHERE PotSet.sequence > 0 AND PotSet.primeMsgID = POSet.primeMsgID AND POSet.fuzzy = FALSE AND POSet.sequence > 0 AND (SELECT COUNT from POTranslationSighting POSighting WHERE POSighting.POMessageSet = POSet.id AND POSighting.inLastRevision = TRUE) = 0 AND (SELECT COUNT from POTranslationSighting RosettaSighting WHERE POSighting.POMessageSet = POSet.id AND POSighting.active = TRUE) > 0
[04:13] <lalo> but the syntax I used for subqueries is pseudolanguage, I don't think that would actually work
[04:14] <carlos> lalo: the POSet.sequence > 0 should be removed
[04:14] <carlos> also,  (SELECT COUNT from POTranslationSighting POSighting WHERE POSighting.POMessageSet = POSet.id AND POSighting.inLastRevision = TRUE) = 0
[04:14] <carlos> that's incorrect
[04:15] <lalo> that's what I just said :-)
[04:15] <carlos> I mean
[04:15] <carlos> it should be > 0 :-)
[04:15] <lalo> ah, ok
[04:15] <lalo> right, I think I typed on inertia :-)
[04:16] <lalo> it's not SELECT COUNT, tough - what is it?
[04:16] <carlos> SELECT COUNT(*)
[04:16] <lalo> thanks
[04:17] <lalo> it's not "=0" - it's correct
[04:17] <lalo> check again
[04:17] <carlos> ?
[04:17] <lalo> your first correction, it's already the way you say
 lalo: the POSet.sequence > 0 should be removed ?
[04:18] <lalo> DUDE, I'M AWESOME :-p
[04:18] <lalo> WHERE PotSet.sequence > 0 AND PotSet.primeMsgID = POSet.primeMsgID AND POSet.fuzzy = FALSE AND POSet.sequence > 0 AND (SELECT COUNT from POTranslationSighting POSighting WHERE POSighting.POMessageSet = POSet.id AND POSighting.inLastRevision = TRUE) = 0 AND (SELECT COUNT from POTranslationSighting RosettaSighting WHERE POSighting.POMessageSet = POSet.id AND POSighting.active = TRUE) > 0
[04:18] <lalo> oops, pasted the old one again, sorry
[04:18] <lalo> SELECT COUNT(*) from POMsgSet PotSet, POMsgSet POSet WHERE PotSet.sequence > 0 AND PotSet.primeMsgID = POSet.primeMsgID AND POSet.fuzzy = FALSE AND POSet.sequence > 0 AND (SELECT COUNT(*) from POTranslationSighting POSighting WHERE POSighting.POMsgSet = POSet.id AND POSighting.inLastRevision = TRUE) = 0 AND (SELECT COUNT(*) from POTranslationSighting RosettaSighting WHERE RosettaSighting.POMsgSet = POSet.id AND RosettaSighting.active = TRUE) > 0;
[04:18] <lalo> this one runs and prints the right result
[04:19] <lalo> awesome :-P
[04:19] <carlos> POSet.sequence > 0 <--- That's incorrect
[04:19] <lalo> why?
[04:19] <carlos> because the that pomsgset could be out of the .po file last time we imported it
[04:20] <carlos> you only need to check the potset
[04:20] <lalo> yes, well
[04:20] <lalo> I'm looking for only subset 2 here
[04:20] <lalo> I suppose if I remove that clause I get the entire correct query for rosettaCount, but I haven't looked into that yet
[04:21] <carlos> please, could you explain me this:
[04:21] <carlos> (SELECT COUNT(*) from POTranslationSighting POSighting WHERE POSighting.POMsgSet = POSet.id AND POSighting.inLastRevision = TRUE) = 0
[04:22] <carlos> the inLastRevision != than "it exists in the .po file"
[04:22] <lalo> if this message set has any translations that come from SCM, we're not interested on it
[04:23] <carlos> you have a conceptual error
[04:23] <carlos> that's origin != 1
[04:23] <carlos> or even better origin == 2
[04:23] <lalo> I assume inLastRevision means "it exists in the *latest* import file", which is more useful than "it exists in the .po file"
[04:24] <carlos> no, that's not true
[04:24] <lalo> ok
[04:24] <carlos> that flag is to know, when we have more than one translation
[04:24] <carlos> which one is the newer one
[04:25] <lalo> hmm, no, that's "active" and "dateLastActive"
[04:26] <lalo>     inLastRevision = Attribute("True if this sighting is currently in the upstream POFile, otherwise false.")
[04:26] <lalo>     origin = Attribute("Where the sighting originally came from.")
[04:26] <carlos> let me check...
[04:26] <lalo> actually it would be wrong to query on origin, because a translation may have been first submitted into Rosetta, then later incorporated into SCM, and origin would still be Rosetta
[04:27] <lalo> but I should probably add "active = TRUE" to both subqueries
[04:28] <carlos> lalo: that's why you need to check that it's not already in a po file we imported
[04:28] <carlos> hmm 
[04:28] <lalo> which is precisely what I'm doing :-)
[04:28] <carlos> I'm not completely sure about all this
[04:29] <lalo> me neither
[04:30] <lalo> my sql level is far from wizard
[04:30] <carlos> ok, that's what I know about all this (or I thought I know)
[04:30] <carlos> daf: ping
[04:30] <daf> pong
[04:30] <carlos> daf: we need you
[04:30] <lalo> but I'm quite sure about the meaning of the columns
[04:30] <carlos> ok
[04:30] <daf> carlos: what's the problem?
[04:31] <lalo> daf: I suppose you have to scroll back :-) up to "oops, pasted the old one again, sorry", I believe
[04:32] <carlos> potranslationsighting.active is equal TRUE when it's a useful translation and equal to FALSE if it's not valid (like a German translation that was imported by error into a Spanish translation)
[04:32] <carlos> potranslationsighting.inlasttranslation is equqal TRUE if it's that translation is the latest one revised so we should only export that one
[04:33] <lalo> carlos: yes - so we want to completely discard these, or we'll have bogus numbers on the query
[04:33] <carlos> and equal FALSE if we change the translation with a new one (from a po import or from rosetta)
[04:33] <lalo> no, that's not correct, at least not according to the interface and to how we've been using it
[04:34] <lalo> a translation from Rosetta is *not* inLastRevision
[04:34] <carlos> why?
[04:34] <carlos> I mean
[04:34] <lalo> because it's not in revision at all
[04:34] <carlos> how are you mapping it with our database?
[04:34] <lalo> "revision" means SCM in this context
[04:35] <carlos> lalo: no, that's why we renamed from "inPoFile" to "inLastRevision"
[04:35] <lalo> precisely
[04:35] <daf> I think the documentation for "inLastRevision" is misleading
[04:36] <carlos> lalo: it makes no sense to have a flag that only tells us if a translation is in SCM but not in rosetta, that's the point of origin
[04:36] <lalo> no
[04:36] <lalo> origin means where it's from *originally*
[04:36] <carlos> daf: the one in interfaces.py?
[04:36] <daf> carlos: yes
[04:37] <carlos> daf: do we agree then
[04:37] <lalo> I don't know why we want to know that, but that's what it is :-)
[04:38] <carlos> lalo: Could you explain me why do you think the rename from inPoFile to inLastRevision is so natural to use the way you think?
[04:38] <lalo> the code states somewhere that origin never changes
[04:38] <carlos> lalo: origin must not be changed
[04:38] <carlos> :-)
[04:38] <carlos> we agree on that
[04:38] <lalo> then I'm right
[04:39] <carlos> no :-P
[04:39] <lalo> if you create a translation in Rosetta, then incorporate it in SCM, and import the PO, origin is still Rosetta
[04:39] <carlos> or I'm wrong, but I don't see it yet :-)
[04:39] <carlos> lalo: right
[04:39] <lalo> but inLatestRevision is True
[04:39] <carlos> when you insert a new translation from Rosetta
[04:39] <carlos> inLastestRevision should be changed to True
[04:39] <carlos> for the new insert
[04:39] <carlos> and the old ones changed to False
[04:40] <lalo> can you rephrase your question about the column renaming? I couldn't parse it
[04:41] <carlos> when I told you about the rename, you told me "<lalo> precisely"
[04:41] <carlos> so I suppose that with the rename you see it as a better name to use it that way
[04:41] <carlos> and I think we renamed it to prevent the rationale you are thinking :-)
[04:41] <lalo> precisely - inPOFile could mean "In any PO File", while inLatestRevision means "in the PO File present in the latest revision of whatever SCM upstream uses"
[04:42] <lalo> you remember wrong :-)
[04:42] <carlos> daf: could we know your point of view?
[04:42] <carlos> lalo: perhaps
[04:42] <lalo> we renamed to make it *clearer* that it's about SCM
[04:43] <daf> inLastRevision is not about SCM
[04:43] <daf> because it's also necessary for Rosetta translations
[04:43] <lalo> how so?
[04:43] <lalo> if it's not about SCM, then it's misnamed, and I'm pretty sure that's not the case.
[04:43] <daf> when you create new transaltions through the web, you need to indicate that the translation sightings you're creating are current
[04:44] <daf> which is done by setting inLastRevision to True
[04:44] <lalo> I believe that's an incorrect usage of the field
[04:44] <carlos> lalo: take it as "in last revision of the translation"
[04:44] <daf> (I think)
[04:44] <daf> now I'm confused also
[04:44] <lalo> if neither of us is sure, we should ask Mark
[04:44] <carlos> daf: that's what I thought
[04:45] <lalo> (in fact I *am* sure, but I'm minority :-P)
[04:45] <carlos> lalo: yes, perhaps it's a good thing to do
[04:45] <daf> lalo: if I'm wrong, so is the code
[04:45] <daf> sigh
[04:45] <daf> this should not be unclear
[04:45] <lalo> same for me :-0
[04:45] <carlos> and fix our interface documentation
[04:45] <lalo> if I'm wrong, there are a few places that must be fixed
[04:45] <daf> ok, a question:
[04:46] <daf> if inLastRevision doesn't indicate that a translation sighting is the one that is current for a message set, what does?
[04:46] <lalo> active
[04:47] <lalo> and if you have more than one active, you want the one with the latest lastActive timestamp
[04:47] <carlos> lalo: then, how could we mark some translations that are completely wrong to be "deprecated"?
[04:47] <daf> lalo: that's a field on message sets, isn't it?
[04:47] <lalo> no
[04:48] <lalo> maybe there is one in message set too, but I'm talking about translation sighting
[04:48] <carlos> active and inlastrevision comes from potranslationsighting
[04:49] <carlos> there is another inlastrevision for the pomsgsets
[04:49] <carlos> no, sorry
[04:49] <carlos> a typo in my sql query :-P
[04:50] <daf> carlos: I think Lalo is correct
[04:51] <carlos> daf: then, could you (or lalo) write it down in any place
[04:51] <carlos> so it's clear?
[04:51] <carlos> for instance the interfaces.py
[04:51] <carlos> BTW, I think we should validate it with Mark before doing any change
[04:54] <lalo> sabdfl: ping?
[04:54] <lalo> (doesn't hurt to try)
[04:55] <daf> he's on the phone
[05:15] <lalo> daf: and what about the other two tasks? any preference?
[05:16] <lalo> or maybe you have some other task for me I wasn't thinking about?
[05:19] <daf> no, I don't
[05:19] <lalo> argh. Made 4 commits with the wrong tla id :-/
[05:19] <daf> I don't think I have a preference for the order
[05:19] <lalo> ok
[05:19] <daf> lalo: all-to-easily done
[05:22] <carlos> daf: did you tested the po export I asked this morning?
[05:22] <daf> no, I didn't
[05:22] <daf> I've just merged from RF
[05:22] <daf> I'll do it now
[05:23] <carlos> ok, thanks
[05:25] <daf> https://rosetta.warthogs.hbd.com/rosetta/projects/gnome/evolution/evolution-2.0/translate?offset=15
[05:25] <daf> \o/
[05:26] <dilys> Bug 2057 resolved: Highlight interpolations in c-format messages
[05:26] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2057
[05:27] <carlos> daf: hmmm, good feature :-P, but please, change the color :-D
[05:28] <daf> I was feeling lazy :)
[05:28] <daf> if you like, feel free to make it better
[05:28] <daf> carlos: export seems to still work for me
[05:29] <carlos> daf: :-P
[05:29] <lalo> hmm. LP doesn't run for me :-(
[05:29] <carlos> the functional tests works?
[05:30] <daf> lalo: UTC_NOW error?
[05:30] <lalo> yes
[05:30] <daf> lalo: fixed in RF
[05:32] <lalo> wha? but I just merged in
[05:32] <lalo> o.O
[05:33] <daf> https://chinstrap.warthogs.hbd.com/archzoom/rocketfuel@canonical.com/launchpad--devel--0--patch-451?log
[05:51] <sabdfl> lalo: pong
[05:51] <lalo> hello
[05:51] <sabdfl> hey
[05:51] <lalo> we're confused about the inLastRevision field of POTranslationSighting, again :-)
[05:51] <sabdfl> ok
[05:52] <lalo> I believe it means that translation is in SCM - is that correct?
[05:52] <sabdfl> afaicr it means it was present in the last SCM version we parsed
[05:52] <lalo> s/believe/am pretty sure/
[05:52] <carlos> well, it should mean the same in pomsgset, potranslationsighting and pomsgidsighting
[05:52] <sabdfl> yes
[05:52] <carlos> sabdfl: and the active field?
[05:53] <sabdfl> that's to indicate the one we would give as the *current best*
[05:53] <sabdfl> so say we parse a PO file from SCM and find a new translation
[05:53] <sabdfl> that becomes true in both inlastrevision and active
[05:53] <sabdfl> then, someone gives us a new translation over the web
[05:54] <sabdfl> that becomes active=true, but inlastrevision=false
[05:54] <sabdfl> wile the old one remains inlastrevision=true
[05:54] <sabdfl> then the maintainer downloads the po from us
[05:54] <sabdfl> we give him the translations that have active-true
[05:54] <sabdfl> so he gets the new one
[05:55] <sabdfl> he commits it
[05:55] <sabdfl> we sync from scm
[05:55] <sabdfl> and parse the po file
[05:55] <sabdfl> we see the new translation in there, so we mark it inlastrevision=true
[05:55] <sabdfl> of course that means the old one is now inlastrevision=false
[05:55] <sabdfl> clearer?
[05:55] <carlos> then, we should set active = false for the old ones when we get a new translation
[05:55] <carlos> ?
[05:57] <carlos> if that's the case, we don't have a way to "disable" bad translations (like german strings imported by error as Spanish ones)
[05:57] <lalo> didn't we use to have an obsolete field?
[05:58] <lalo> what I'm doing now is to assume there are more than one with "active = TRUE" and fetch the one with the latest lastActive timestamp
[05:58] <carlos> lalo: it was renamed to active :-)
[05:58] <lalo> carlos: ah.
[05:58] <lalo> my head hurts :-p
[05:59] <sabdfl> lalo: no, there should only ever be one with active=true and one with inlastrevision=true
[05:59] <lalo> ok
[06:00] <carlos> sabdfl: then, what should we do with the case I'm talking about?
[06:00] <lalo> so we still need a field for a translation that should be completely disregarded
[06:01] <lalo> "deprecated" or "deleted" or something
[06:01] <sabdfl> carlos, lalo, i have to be in #ubuntu-meeting for a meeting, catch me afterwards
[06:01] <carlos> ok
[06:01] <carlos> sabdfl: later
[06:02] <carlos> lalo: could you write down all this so we don't get confused again? (I'm asking you because seems like you know it well)
[06:03] <lalo> ok
[06:03] <carlos> also, we should review all code and fix it so it works that way :-(
[06:03] <daf> carlos: can you file a bug on that?
[06:03] <carlos> daf: sure
[06:03] <lalo> I'll expand on the docstrings that are currently in the interfaces. But these docstrings are correct
[06:03] <lalo> (the ones that exist)
[06:04] <carlos> lalo: ok
[06:04] <carlos> that's even better than a document
[06:04] <daf> carlos: changing the colour of the hilighting is a one-line change to launchpad.css, by the way
[06:04] <daf> lalo: great!
[06:04] <daf> carlos: yeah, we should add some there
[06:05] <carlos> daf: don't worry, the hard part is done the UI changes could come from limi :-P
[06:05] <daf> carlos: true
[06:05] <daf> carlos: I think limi is really busy at the moment, though
[06:05] <daf> carlos: Malone and Lurker are higher priorities for him right now
[06:05] <carlos> do we have already a timeline for the beta and the final release?
[06:06] <daf> no
[06:06] <carlos> I know
[06:06] <daf> once we decide on all the features we want in the beta, then we can estimate how long each one will take and how long the beta will take
[06:07] <carlos> I thought we had a timeline for the final release already 
[06:07] <carlos> (something like warty release date)
[06:08] <carlos> that's why I'm asking
[06:08] <daf> I can't remember :)
[06:08] <lalo>      Untranslated messages: -32     
[06:08] <lalo> :-P
[06:09] <carlos> lalo: yes, that one is funny
[06:12] <carlos> X-)
[06:12] <carlos> seems like somepeople is going to do the same we are doing with arch but with subversion
[06:12] <carlos> for GNOME
[06:13] <lalo> hmm, I can't set language preferences at all in my local lp
[06:14] <carlos> lalo: it should not be a problem anymore, I did a patch so pt_BR should work
[06:14] <lalo> yes
[06:14] <carlos> and it's in rocketfuel since yesterday or even earlier
[06:15] <lalo> but I can't choose *at all* right now, regardless of country code
[06:15] <lalo> eg if I choose Arabian and Chinese it breaks
[06:15] <carlos> could you show me a traceback?
[06:16] <lalo> I can't get to the debug skin either :-/
[06:17] <dilys> New bug 2065 for Launchpad/Rosetta: Review all code so we are using the database as it should
[06:17] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2065
[06:18] <carlos> lalo: It works here with latest code from rocketfuel
[06:19] <lalo> bummer
[06:20] <lalo> http://localhost:8085/++skin++Debug/rosetta/ -> 404
[06:20] <lalo> is this the right url?
[06:20] <daf> make debugging-on?
[06:20] <daf> see you all later
[06:20] <lalo> hmm
[06:20] <carlos> nice, the ++skin++Debug works with authentication now :-P
[06:20] <carlos> daf: later
[06:20] <lalo> it is disabled by default? I didn't know about that change
[06:21] <lalo> later daf, boa viagem
[06:22] <carlos> lalo: It was disabled always
[06:22] <carlos> you need to copy a file (that's what make debugging-on does)
[06:22] <carlos> to activate it
[06:22] <lalo> but it used to work for me
[06:22] <lalo> o.O
[06:22] <carlos> did you checked out launchpad recently?
[06:23] <lalo> ah, duh
[06:23] <lalo> yes
[06:23] <carlos> that's the problem :-P
[06:23] <lalo> I threw away my old tree
[06:23] <carlos> you have lost the file :-)
[06:23] <lalo> that's when :-)
[06:25] <lalo> carlos: can you get to my IP maybe? http://201.10.27.117:8085/++skin++Debug/rosetta/prefs
[06:25] <carlos> yes
[06:25] <lalo> great :-)
[06:25] <carlos> I'm in
[06:26] <carlos> but it's slow...
[06:26] <carlos> I see the error
[06:27] <carlos> lalo: are you using your sqlobject branch?
[06:27] <carlos> because I think that's the problem, that you are not using it...
[06:28] <carlos> not sure, but it's similar to a problem I had with the scripts until I moved to your sqlobject branch
[06:31] <lalo> I believe I am
[06:31] <lalo> let me check
[06:32] <lalo> ah, well, of course I am, otherwise my script would not be running
[06:32] <carlos> and are you using latest version of the database?
[06:33] <lalo> yes
[06:33] <carlos> then I don't understand it
[06:33] <lalo> well, latest as of two or three days. Should I recreate it?
[06:33] <carlos> any pending change to commit into rocketfuel?
[06:33] <carlos> hmm
[06:33] <carlos> yes, please
[06:33] <carlos> I'm not sure if it could be an issue
[06:34] <carlos> but I did somechanges that perhaps sqlobject is not able to handle without the indexes or unique keys in the database
[06:34] <lalo> yes, but none in code that is at all touched by this prefs page - I have changes to pofile_adapters, poimport.py and sql.RosettaPOFile.updateStatistics()
[06:34] <carlos> ok, let's try the db tehn
[06:43] <lalo> done
[06:44] <lalo> carlos: that fixed it   O.o
[06:44] <carlos> perfect
[06:44] <lalo> thanks
[06:51] <lalo> carlos: I get an error if I try to add english :-P
[06:51] <carlos> same error?
[06:51] <carlos> let me check
[06:51] <lalo> looks like - I don't have the old one around anymore to compare
[06:53] <carlos> yes, same error
[06:54] <carlos> and it fails also here
[06:55] <carlos> I think I know where is the problem, but I don't know why It's a problem...
[06:56] <carlos> could you file a bug report?
[06:56] <lalo> ok
[06:59] <lalo> hmm, I don't seem to have plural form info in the db - is it being imported by the makefile?
[07:02] <lalo> ah, well, nm
[07:02] <lalo> I do have that info
[07:03] <lalo> only I thought it did have info on some of the languages I chose, and it doesn't :-)
[07:03] <carlos> phone
[07:15] <dilys> New bug 2066 for Launchpad/Rosetta: Error if I add English to my languages
[07:15] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2066
[07:18] <dilys> New bug 2067 for Launchpad/Rosetta: Translate page: Batch widget on the bottom too
[07:18] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2067
[07:19] <lalo> ok, now I have translations I can test statistics against.
[07:34] <lalo> ARGH
[07:36] <lalo> #2042 now depends on #2065 :-/
[07:39] <dilys> Bug 2058 resolved: Show template completeness statistics on translation page
[07:39] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2058
[07:40] <lalo> I'll take a break, I'm hurting all over
[07:40] <lalo> bbl
[07:42] <carlos> lalo: yes, we should have it fixed for the beta
[07:44] <carlos> hmm
[07:44] <carlos> sorry, I saw #2065 and I thought about #1965 :-P
[07:55] <lalo> it would be rather interesting for a bug to depend on 1965 :-P "I can't fix this unless the beta is released"
[07:57] <spiv> lalo: I guess the final release would ;)
[08:10] <sabdfl> ok, i'm back
[08:19] <carlos> sabdfl: we were talking about a missing field
[08:20] <carlos> we need a way to set a potranslationsighting as "wrong" so we don't care about it ever
[08:20] <carlos> if we see it again from a pofile we could forget about it because we already know it will be wrong
[08:20] <carlos> with the scenario we were talking we don't have such flag
[08:20] <carlos> (or I don't see it)