[01:29] <xhaker> hey peeps
[01:30] <xhaker> is there any dup finder in malone?
[01:52] <jamesh> lifeless: any progress on getting pygpgme branched into rocketfuel?
[01:52] <lifeless> jamesh: not yet, I have to get the bzr/bzrtools thing done 
[01:52] <lifeless> jamesh: which is on the plan for today
[01:52] <jamesh> fair enough.
[01:52] <lifeless> jamesh: until thats done, the test suite will barf on your branch
[01:53] <lifeless> jamesh: if its 'done' I can manually wedge it in but you can't commit to it until later. Is that ok ?
[01:54] <jamesh> lifeless: that's fine.  I'd be able to commit the configs and launchpad bits though?
[01:54] <lifeless> yes
[01:54] <lifeless> I can do this now. one sec
[01:54] <jamesh> thank you.
[01:59] <lifeless> done
[02:13] <jamesh> lifeless: should I be able to see the pygpgme directory in chinstrap:/home/warthogs/archives/rocketfuel ?
[02:14] <lifeless> jamesh: uh no. my bad
[02:19] <rob_conscience> lifeless: it's your conscience talking to you
[02:19] <rob_conscience> lifeless: you've got to reply to ddaa's annoying questions about the bzr transition plan
[02:20] <lifeless> thanks
[02:27] <ddaa> sigh...
[02:27] <ddaa> got to start the GIMP import... again...
[02:27] <ddaa> this is a curse...
[02:27] <lifeless> whats breaking it ?
[02:28] <ddaa> reboots
[02:28] <ddaa> last time I was tempted to actually salvage the .bzr from the previous import
[02:29] <ddaa> but then I thought that it was probably best to play stupid
[02:29] <lifeless> jamesh: done
[02:30] <jamesh> ddaa: you know most stuff in gnome CVS will be in Subversion by middle of next month?
[02:31] <ddaa> jamesh: LALALAL what did you say LALALALA
[02:32] <ddaa> lifeless: do you have any idea how we may handle this sort of CVS->SVN transition?
[02:32] <lifeless> ddaa: 'rm'
[02:32] <lifeless> ddaa: or
[02:32] <ddaa> I mean, in a vaguely seamless manner...
[02:32] <lifeless> ddaa: change the source at the revision it cuts over, and write a revision that has no content changes and the CSCVS metainformation to match svn
[02:33] <lifeless> vaguely scriptable if we care to
[02:33] <ddaa> well, the good news is that SVN is much easier to import from...
[02:34] <ddaa> the bad new is than SVN support is still... lacking...
[02:34] <lifeless> I've replied
[02:34] <jamesh> ddaa: one of the ideas going round at the moment is to edit the RCS timestamp history so that the cvs2svn migration doesn't corrupt the history ...
[02:35] <ddaa> gn?
[02:35] <jamesh> (on the gnome side)
[02:35] <ddaa> you know, you make me want to pull my eyes out...
[02:36] <lifeless> ddaa: just think of lamont 
[02:36] <ddaa> "let's scramble our history, so the broken SVN transition script, the broken SVN revision model, and the broken SVN date logic does not prevent use to use dates"
[02:37] <ddaa> "and while we are at it we will have a big party where we will all nail one another's scrotum on a plank"
[02:37] <ddaa> lifeless: what with lamont?
[02:38] <jamesh> ddaa: it's more of a case that our history is scrambled, and needs unscrambling
[02:38] <lifeless> ddaa: lamont ran RCS scripts across his postfix repository, repeatedly
[02:38] <lifeless> ddaa: a major source of bugfinders for cscvs
[02:39] <jamesh> ddaa: there have been clock skew problems at various points in the past, and the conversion scripts don't like it.
[02:39] <ddaa> jamesh: I do not understand, the problem I'm aware of is that branch-wise import to svn cause the repository to end up with non-monotonous dates
[02:40] <ddaa> which fucks up finding revisions by dates
[02:40] <jamesh> ddaa: no.  Part of the linear history of a single file goes 2003, 2003, 1997, 1997, 2003
[02:40] <ddaa> (but which leaves cscvs utterly indifferent as long as it imports along the branch boundaries)
[02:41] <jamesh> that's what is fucking up cvs2svn
[02:41] <ddaa> well, that's CVS... what were they thinking???
[02:41] <ddaa> you mean the cvs2svn people thought that CVS was what? Reliable???
[02:41] <jamesh> well, CVS just recorded the timestamp the system clock gave it
[02:42] <ddaa> dates in particular... it's stupid to rely on those for conversion logic...
[02:42] <ddaa> for anymore than rought heuristics
[02:42] <ddaa> jamesh: anyway, that's a very interesting data point
[02:43] <ddaa> jamesh: please keep us posted
[02:45] <ddaa> lifeless: lamont knows enought RCS voodoo to write fantastic novels about it.
[02:45] <ddaa> I mean CVS voodoo.
[02:45] <ddaa> I mean fantasy novels too.
[02:45] <lifeless> ddaa: nono, he ran *RCS* against his *CVS* repository.
[02:46] <lifeless> its an unversioned file format.
[02:46] <ddaa> I supposed that involved an obfuscated Perl contest, did it?
[02:47] <ddaa> I propose we stop CVS imports BTW and just wait for everybody to switch to SVN
[02:47] <ddaa> that should not take much longer
[02:53] <ddaa> lifeless: apparently you did not read the contexts of the questions...
[02:53] <ddaa> the documentation contains the explicit bzr configuration I plan to use
[02:54] <lifeless> ddaa: what would you like me to revisit
[02:55] <ddaa> nothing specific so far, you happened to reply to the question. It was the "belt and suspenders" and you replied "dunno".
[02:55] <lifeless> right. I dont know if there is such a facility in bzr
[02:56] <ddaa> oh, also you said something about checking own signatures, I did not understand
[02:56] <ddaa> that was a question about a very specific configuration point
[02:56] <lifeless> you asked if import should check its own signatures
[02:57] <lifeless> I did not understand it to be a configuration question
[02:57] <lifeless> if it was a configuration question I would have expected 'should we set KNOB to VALUE or VALUE'
[02:58] <lifeless> anyway, signature checking in bzr is still not finished, though they can be manually checked.
[02:58] <lifeless> so if you are asking 'should we configure bzr to check its own signatures' the answer is 'you cannot'
[02:58] <ddaa> well... then the documentation on the wiki is misleading...
[02:59] <lifeless> that mutated from a proposal to a misleading 'active' document
[02:59] <mpt> Goooooooooooooooooooooooooooood afternoon Launchpadders!
[03:00] <lifeless> I'm being called for lunch
[03:00] <lifeless> sleep well ddaa
[03:00] <lifeless> tchau
[03:01] <ddaa> good day, thanks for the fast answer
[03:33] <spiv> jamesh: ping
[03:41] <lamont> lifeless: I only ran rcs across my cvs tree twice... once to break it (well, not on purpose...) and once to undo the b0rkage...  that's not really "repeatedly"
[04:13] <jamesh> spiv: pong
[04:13] <spiv> jamesh: two things...
[04:14] <jamesh> your sftp mirror branch?
[04:14] <spiv> jamesh: one is that I'm curious to know how the review of spiv/launchpad/supermirrorsftp-integration is going?
[04:14] <spiv> Yeah, if you're too busy we can find someone else.
[04:14] <spiv> Also, I hear you're doing something with XML-RPC for branches?
[04:15] <spiv> There may be some overlap perhaps with my branch in your review queue, which adds some XML-RPC methods to the authserver that the SFTP server needs.
[04:16] <jamesh> I have only taken a brief look over the supermirror branch, but I can probably send thereview comments early next week
[04:16] <jamesh> I'm working on some code to allow the branch puller to use XML-RPC to update the status of the branch in LP
[04:18] <spiv> Actually, now that I look, I see that the XML-RPC bits of that branch already got merged accidentally in an earlier merge.
[04:21] <spiv> jamesh: Well, the existing XML-RPC for branches I have is in the authserver, just the getBranchesForUser, fetchProductID and createBranch methods.  Are you adding to the authserver (which really needs a new name)?
[04:22] <spiv> jamesh: Perhaps the thing to do with the review is put it on rejected list -- you can always take it back if no-one else gets there first :)
[04:22] <jamesh> spiv: I'm adding to the authserver, but I was planning on putting these methods under a separate endpoint, to simplify things if we need to update the methods I add, or the authserver bits need changes
[04:22] <jamesh> seemed the most sensible thing to do
[04:23] <spiv> jamesh: Sounds sensible.  I should look over it when you merge, and update my branch-related methods to do the same thing, probably.
[04:24] <spiv> Anyway, that's all I wanted to know.  Thanks!
[04:35] <lifeless> lamont: once is once, twice is repeated :)
[04:36] <lamont> feh - the second time was minus-one
[04:37] <lamont> lifeless: your test suite, otoh, does it every time... :0)
[04:39] <lamont> anyway, bedtime for me, I think
[04:51] <mpt> ha!
[04:52] <mpt> The page for adding a source release to a mirror uses the form intended for adding an arch release
[05:38] <jbailey> stub: Around?
[05:39] <stub> jbailey: yes
[05:39] <jbailey> stub: I'm curious - What do you think of the idea of rejecting or fixed-releas'ing all the debbugs-imported tasks in Malone?
[05:40] <jbailey> AFAICT they're not collecting status updates, and they're polluting the subscribed lists because they keep bugs artificially open.
[05:40] <stub> I think we should put the debbugs synchronization code into production so they are updated
[05:40] <jbailey> Ah, that would be even better.  I hadn't realised that was planned.
[05:41] <stub> I'd rather delete all the imported tasks than give them an incorrect status
[05:41] <stub> Mark wrote the code ages ago. It needs someone to update and test it. However, there have been discussions on how debbugs watches should be handled that I haven't been following closely.
[05:43] <jbailey> stub: Nice to know, thanks.  I was just surprised when your query still left me with a surprising number of bugs.
[05:45] <stub> I'd discuss how it should be handled with brad and maybe kiko. Make sure they are on the right track.
[05:45] <jbailey> Cool.
[05:45] <jbailey> Thanks again for running that other query!
[09:00] <carlos> morning
[09:07] <mpt__> How do I add a milestone to a product?
[09:07] <mpt__> oh, I can do it for a product but not a package
[09:07] <mpt__> grmph
[09:14] <mpt__> jamesh, perhaps you'd be interested in implementing bug 28655
[09:14] <Ubugtu> malone bug 28655 in launchpad ""Constraint not satisfied" should be reworded and trigger a logged error" [Normal,Confirmed]  http://launchpad.net/bugs/28655
[09:34] <SteveA> mpt: i'm not sure i agree with bug 28655
[09:34] <Ubugtu> malone bug 28655 in launchpad ""Constraint not satisfied" should be reworded and trigger a logged error" [Normal,Confirmed]  http://launchpad.net/bugs/28655
[09:36] <SteveA> i think we should change the error message to read "a field is incorrect" or "this field in incorrect"
[09:36] <SteveA> but i don't think we should log errors yet
[09:36] <SteveA> because we have so many more significant errors already
[09:39] <mpt> SteveA, so the amount added to the bottom of the report would slow down those fixing the bugs in the more important categories?
[09:40] <SteveA> even just *thinking* about this right now, for anyone except you, is a poor choice of focus
[09:41] <mpt> ok
[10:07] <SteveA> jamesh: i made some progress on the oops.cgi feature
[10:08] <SteveA> the latest oops summary is interesting.  i think the analysis script is applying the regexes in the wrong order, perhaps
[10:08] <SteveA> compare these two consecutive entries
[10:08] <SteveA> 5 ProgrammingError: ERROR: duplicate key violates unique constraint "sessiondata_key" INSERT INTO SessionPkgData (client_id, product_id, key, pickle) VALUES ( $STRING, $STRING, $STRING, $STRING)
[10:08] <SteveA>     *
[10:08] <SteveA>     o
[10:08] <SteveA> 1 ProgrammingError: ERROR: duplicate key violates unique constraint "sessiondata_key" INSERT INTO SessionPkgData (client_id, product_id, key, pickle) VALUES ( $STRING, $STRING, $STRING, $STRING\\\\$INT\\\\$INT\\\\$INTRq\\\\$INTsb.')
[10:10] <jamesh> SteveA: that looks weird.
[10:10] <jamesh> SteveA: it replaces strings before integers, which I think is the correct order
[10:11] <jamesh> I guess the regexp for strings didn't handle the string in question
[10:11] <SteveA> yeah
[10:11] <SteveA> i guess so
[10:11] <SteveA> these are pickles i think
[10:13] <SteveA> jamesh: my changes are in ~stevea/public_html/oops.cgi
[10:13] <SteveA> there is now a simple "time saving for repeated queries" analysis at the end of the page
[10:13] <SteveA> some of the variable names i used could be made more consistent with what you use
[10:13] <SteveA> because i was importing code from some other code i wrote earlier
[10:14] <SteveA> and i was being lazy late at night
[10:15] <SteveA> daf: hi
[10:15] <SteveA> daf: there is an oops that could use some code to give a better error message
[10:15] <SteveA>   Module canonical.launchpad.database.sourcepackage, line 179, in <lambda>
[10:15] <SteveA>     key=lambda item: Version(item.version))
[10:15] <SteveA>   Module sourcerer.deb.version, line 85, in __init__
[10:15] <SteveA>     raise BadUpstreamError, "Bad upstream version format"
[10:15] <SteveA> BadUpstreamError: Bad upstream version format
[10:15] <SteveA> 
[10:15] <SteveA> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-02-16/D78
[10:15] <SteveA> 
[10:15] <SteveA> the problem is, the code says BadUpstreamError "Bad upstream version format", but then it doesn't tell you what version format was passed in
[10:16] <jamesh> SteveA: I wonder if it would be worth putting the SQL statement summary above the full log?
[10:16] <SteveA> so you don't easily have the data that caused the error
[10:16] <daf> do you suggest chaning sourcerer or catching the exception in hte database code and re-raising it with more information?
[10:16] <SteveA> jamesh: yeah, i think so
[10:17] <daf> SteveA: ^^^
[10:18] <SteveA> is there any more information we need than item.version ?
[10:18] <SteveA> if item.version is enough, then we should improve sourcerer
[10:18] <daf> it should be enough
[10:19] <SteveA> ok.  then sourcerer.
[10:19] <SteveA> it should be a simple change, and will allow us to see better what the problem is
[10:19] <SteveA> although... 
[10:19] <SteveA> if the OOPS reports for errors could show the value of locals
[10:19] <SteveA> or even locals going up the stack
[10:19] <SteveA> that would be even better
[10:19] <SteveA> jamesh: do you think that is feasible?
[10:19] <daf> that would be great
[10:19] <SteveA> daf: although, the error in sourcerer should be fixed
[10:20] <daf> agreed
[10:20] <SteveA> daf: would you take care of the paperwork ? ;-)
[10:20] <jamesh> SteveA: it'd be possible if we used a different traceback formatting function (assuming the zope one doesn't have support for that already)
[10:20] <daf> SteveA: certainly :)
[10:21] <SteveA> jamesh: i think there's one in twisted, although i think that one doesn't understand the __traceback_supplement__ stuff
[10:21] <SteveA> so probably best to extend the zope one with code from twisted
[10:21] <SteveA> i'll look into it
[10:21] <SteveA> jamesh: i still need to add your regexes into the time-saved analysis, to take account of multiple queries of the same pattern
[10:22] <SteveA> so the table will grow another column for "number of similar queries"
[10:22] <SteveA> and will display the genericised statement
[10:22] <SteveA> and the saving will be adjusted to take this into account
[10:23] <SteveA> daf: note at the top of the oops report https://chinstrap.ubuntu.com/~stevea/oops.cgi/2006-02-16/D78
[10:23] <SteveA> there is "total sql time", "non-sql time" and "total time"
[10:23] <SteveA> this gives some idea of how much processing is done in database code vs application code
[10:23] <SteveA> well, i mean...
[10:23] <SteveA> by the database vs by the application
[10:24] <daf> right
[10:24] <SteveA> if you ever see a *lot* of non-sql time, then there are things to optimise in the code
[10:24] <SteveA> without considering the database
[10:24] <daf> could we copy your working copy of oops.cgi to ~jamesh/oops.cgi?
[10:24] <SteveA> the total time may be somewhat inaccurate
[10:25] <SteveA> because it uses the stop time of the last database query for that
[10:25] <daf> well, accounting errors are to be expected
[10:25] <SteveA> jamesh: maybe we can add a request-start and request-end time to the oops report?
[10:25] <daf> I wouldn't expect them to be significant, though
[10:25] <SteveA> jamesh: then the total time vs total sql time will be more accurate
[10:25] <SteveA> daf: probably not too significant
[10:25] <jamesh> SteveA: sure.
[10:27] <daf> SteveA: https://launchpad.net/products/launchpad/+bug/31741
[10:27] <Ubugtu> malone bug 31741 in launchpad "sourcerer.deb.version raises BadUpstreamError without the version in question" [Normal,Confirmed]  
[10:27] <SteveA> daf: ta
[10:32] <mpt> "Use this form to ..."

[10:32] <mpt> "... using the form above."
[10:32] <mpt> We should have big animated GIF arrows pointing at the form, too
[10:33] <SteveA> you could give all forms a lurid pink background in CSS
[10:33] <SteveA> that would do it
[10:34] <mpt> Actually, now that I think about it, Microsoft Office 97 had a help system with big animated arrows pointing at the field you had to enter next
[10:36] <SteveA> hey, stub... skype call sometime?
[10:39] <SteveA> jamesh: thinking... what about if i made the traceback formatter output an html fragment.  that way, it can be styled nicely in the web pages and also in oops reports.
[10:39] <SteveA> the styling will be important if i extend it to show locals at each stack level
[10:39] <jamesh> SteveA: that might be a good idea.  Given the way we currently use the reports, that part of the OOPS file is only viewed in an HTML wrapper
[10:41] <cprov> morning all
[10:41] <mpt> hi cprov 
[10:41] <daf> mpt: let's do it!
[10:41] <daf> mpt: it should play a fanfare every time you complete a field
[10:41] <mpt> daf, Valentine's Day was three days ago
[10:41] <mpt> oh
[10:41] <cprov> mpt: hi
[10:42] <SteveA> jamesh: would you copy my oops.cgi in place of yours soon, so that daf and matsubara can use the data today?
[10:42] <SteveA> (without having to do URL hacking)
[10:43] <daf> the other option would be to update the production config and bounce the servers
[10:43] <daf> but I think this way is easier
[10:44] <mpt> The problem with comments in code is that they only work for code that's there
[10:44] <mpt> They're not good for explaining why code is not there
[10:44] <SteveA> daf: james' oops.cgi is the canonical one.  that's the one that all the oops summaries point to
[10:44] <SteveA> and where production bug reports point to
[10:44] <daf> ah, right, the summary
[10:45] <daf> product uses a config value for where the OOPS reports are
[10:45] <daf> production
[10:45] <jamesh> done
[10:45] <daf> thanks James
[10:47] <SteveA> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-02-16/A136  <--- HUUUUUGE
[10:47] <SteveA> in firefox, looking at a page on chinstrap
[10:48] <SteveA> if i hover my mouse cursor over the bottom right of the window, where it says "chinstrap.ubuntu.com [padlock] "
[10:48] <SteveA> it says "MRS Virtual"
[10:48] <daf> gosh, 11s non-SQL time
[10:48] <jamesh> good old Mrs. VD
[10:49] <mpt> Does Mark's middle name start with R?
[10:49] <cprov> stub: something is wrong with the database in mawson -> 
[10:49] <cprov> launchpad_dogfood=# \df to_tsvector
[10:49] <cprov>                    List of functions
[10:49] <cprov>  Schema | Name | Result data type | Argument data types
[10:49] <cprov> --------+------+------------------+---------------------
[10:49] <cprov> (0 rows)
[10:49] <daf> oh my god, it's fuill of queries
[10:49] <jamesh> daf: you saw the analysis of the page in question on lp-devel?
[10:50] <stub> SteveA: 
[10:50] <daf> hmm, I missed that
[10:50] <stub> SteveA: Sure
[10:50] <stub> cprov: whats wrong?
[10:50] <stub> oh - full text shite missing?
[10:50] <cprov> stub:  empty ?
[10:50] <cprov> SteveA: have you looked in the fix you requested in GPG ?
[10:50] <daf> jamesh: what was the Subject?
[10:50] <cprov> stub: It can't be right :(
[10:51] <SteveA> cprov: i looked into it.  i'll tell you about it a bit later.
[10:51] <jamesh> daf: Launchpad Errors for 2006-02-01
[10:51] <cprov> SteveA: something wrong ?
[10:51] <jamesh> and replys
[10:51] <SteveA> cprov: busy with other things right now
[10:51] <SteveA> my brain only context switches between 1 other thing at a time :-)
[10:51] <daf> jamesh: thanks
[10:51] <jamesh> daf: it's partly sqlobject MultipleJoin borkage, partly bad template code and partly the fact that it is trying to display so much data in one page.
[10:51] <daf> oh, MultipleJoin
[10:52] <cprov> stub: don't know what to do, all tools breaks on insertions
[10:52] <cprov> SteveA: okay
[10:52] <daf> jamesh: I would suspect that the Python time is being spent in SQLObject generating all these queries and processing the results
[10:52] <SteveA> daf: yes, that is likely.  also, in the huge tal:repeat
[10:53] <SteveA> a tal:repeat is slow, so having such a large one will slow things down.
[10:53] <daf> is it even getting to the stage of rendering the page?
[10:53] <jamesh> daf: yes.
[10:54] <stub> cprov: Ahh.. \df ts2.ftq shows stuff. The search patch is stuffed.
[10:54] <SteveA> yes
[10:54] <jamesh> daf: you can see the TAL expression evaluation in the traceback
[10:54] <SteveA> look at the traceback
[10:54] <daf> ah, right
[10:54] <daf> too many OOPS reports open at once
[10:54] <stub> Yer - changed the option but didn't uncomment it :-)
[10:55] <stub> cprov: fixed
[10:55] <cprov> stub: let's see
[10:55] <cprov> stub: ProgrammingError: ERROR:  permission denied for relation pg_ts_cfg
[10:57] <cprov> stub: in the same insertion. Do you want to see the full error traceback ?
[10:57] <stub> nah
[10:59] <SteveA> jamesh: can you give me permission to write to your oops.cgi ?  i'm going to be working on this today, and it would be nice if i can make changes available right away
[10:59] <SteveA> (i mean, the directory your oops.cgi is in)
[10:59] <stub> cprov: fixed
[11:00] <cprov> stub: not yet :( -> ProgrammingError: ERROR:  permission denied for function person_sort_key
[11:01] <SteveA> the +allpackages page is screwing us over.  we should disable it, if it won't be fixed by the next rollout
[11:01] <SteveA> in fact, disabling it in production to raise an instant exception would be a good thing for right now
[11:02] <stub> cprov: Whoever is using that hasn't written a test :-/
[11:02] <daf> SteveA: you already have it -- it's rwx to the warthogs group
[11:02] <SteveA> daf: oh, cool
[11:02] <daf> the file itself needs g+w, though
[11:02] <SteveA> thanks jamesh :-)
[11:02] <jamesh> SteveA: okay.  It is g+w and owned by warthogs
[11:03] <cprov> stub: who do you mean ? my current script ?
[11:03] <daf> rwxrwxr-x, group warthogs is standard on chinstrap
[11:04] <stub> Ahh... the code on mawson is now out of date
[11:05] <SteveA> daf: i think i'll add to oops.cgi another report.  one that shows individual statements over 1s
[11:05] <cprov> stub: really ? doesn't cope with the DB age ?
[11:05] <stub> eh?
[11:05] <cprov> stub: I can merge RF nop
[11:05] <SteveA> sometimes we have a problem with much-repeated queries.  other times, we have a problem with a couple of very expensive queries
[11:06] <daf> sounds good
[11:06] <cprov> stub: I thought  DB is from yesterday, so it's the code
[11:07] <stub> cprov: The code I'm using isn't from yesterday, which is the problem
[11:07] <stub> I'm updating it
[11:08] <cprov> stub: which code ? I have a lp-upstream copy from yesterday in mawson, if you need (/srv/launchpad.net/codelines/launchpad-upstream/)
[11:09] <stub> cprov: I was using the production branch to update the db and security stuff instead of head
[11:09] <stub> that function doesn't exist on production yet
[11:09] <cprov> stub: I see
[11:11] <daf> SteveA: yesterday you were talking about removing canonical.rosetta -- did that happen?
[11:12] <SteveA> i have it in a branch, and i thought i'd submitted a merge
[11:12] <SteveA> maybe pqm ate it...
[11:14] <daf> I don't see it on the commits list
[11:15] <stub> cprov: fixe
[11:15] <stub> d
[11:17] <SteveA> daf: replied to your mail.  IndexError is still an error.
[11:17] <cprov> stub: works, thank you !
[11:18] <SteveA> stub: what do you think about doing full text searches on a separate r/o replica?
[11:19] <stub> cprov: I'm approving the db patch in cprov/launchpad/small-fixes with that patch number (patch-40-21-0.sql)
[11:20] <cprov> stub: perfect, thanks again 
[11:20] <stub> SteveA: Nothing special about full text searches - they are just index lookups. 
[11:21] <SteveA> they can be a little out of date
[11:23] <SteveA> daf: another HUUGE one  https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-02-16/C507
[11:23] <stub> SteveA: So we lose some synchronization between reality and search results, and gain what? The full text searches do not burden the database. What burdens the database is stoopid numbers of queries, locks being held open by slow transactions and queries on the huuge tables.
[11:23] <stub> Moving some of the rosetta queries to a read only replica might be better
[11:24] <SteveA> yeah
[11:24] <SteveA> that would be feasible
[11:24] <SteveA> so, when i see search results timing out
[11:24] <SteveA> it is because of locks?
[11:25] <stub> In some cases, yes. In other cases it is because the query needs to be optimized so it is correctly hitting indexes.
[11:27] <mpt> <ul ... tal:condition="context/files">
[11:27] <mpt>   ...
[11:28] <mpt>   <li ... tal:condition="not: context/files">...</li>

[11:30] <SteveA> stub: https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-02-16/C208 , statement 192.  do you know if it is using indexes?
[11:31] <SteveA> i'm interested because although it is asking for a number of rows, it seems to be quite simple
[11:33] <stub> SteveA: There is no statement 192 in that oops
[11:33] <SteveA> sure there is
[11:34] <SteveA> in the first group of statements
[11:34] <stub> Ahh,,,,
[11:35] <SteveA> like, 280 numbers there
[11:35] <SteveA> well, maybe more like 200
[11:35] <stub> SteveA: Yes - that statement hits the indexes and takes about 5.5 seconds.
[11:37] <SteveA> so, the only improvement to it would be better hardware
[11:37] <SteveA> or not performing that query
[11:38] <stub> Query 190 is the slow one. The ugly one that needs to join a few of the biggest tables in the database in odd ways.
[11:38] <SteveA> yeah
[11:38] <SteveA> but i was curious about this one
[11:39] <SteveA> can you do anything about 190?
[11:39] <stub> 192 looks really ugly, but it is quite fast. The huge IN list makes the execution plan unreadable though...
[11:40] <stub> We already have looked at 190 I'm afraid. I'll need to give it another go. I might need to take more drastic action to sort it out (materialized views, partitioning - it will take a while to work it out).
[11:41] <SteveA> ok
[11:45] <SteveA> daf: https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-02-16/A172  <-- can halve the time for this one
[11:47] <daf> great
[11:48] <SteveA> although, even then, it is still too long
[11:48] <daf> about BadUpstreamError -- there's a test for this function that uses assertRaises
[11:48] <SteveA> but, not executing that query twice will be an improvement
[11:48] <daf> should I check that the exception has the version as an argument?
[11:49] <SteveA> no need
[11:49] <SteveA> it is an aid to debugging, rather than the logic of the library
[11:49] <daf> ok
[11:53] <SteveA> stub: skype call
[11:53] <SteveA> ?
[12:10] <papa_lic> greetings!
[12:12] <iwj> How do I mark a bug as a duplicate by email ?  Really, I want to mark the bug as an opposite, but I doubt that's supported :-).
[12:15] <jamesh> iwj: looks like that command is missing from the email UI
[12:15] <BjornT> iwj: sorry, that's not implemented yet, bug 5190
[12:15] <Ubugtu> malone bug 5190 in malone "Malone Email UI Should Support "duplicate" Command" [Normal,Confirmed]  http://launchpad.net/bugs/5190
[12:15] <iwj> Ah, OK.
[12:16] <iwj> Erm, if I want to subscribe to a bug in LP by email, do I really have to send a signed message where the sole content covered by the signature is the word `subscribe' ?!
[12:19] <dilys> Merge to devel/launchpad/sourcecode/sourcerer/: [trivial]  fix bug #31741: sourcerer.deb.version raises BadUpstreamError without the version in question (r166: Dafydd Harries)
[12:22] <BjornT> iwj: well, you can send an email to edit@bugs.launchpad.net, starting with command ' bug $bug_id', if you don't want it to show up as a comment.
[12:22] <BjornT> iwj: btw, we'll remove the requirement of signing the emails soon.
[12:23] <iwj> bjornt: Oh, good.
[12:23] <iwj> Oh, yes, here it says `edit@'.
[12:23] <iwj> (In the doc.)
[12:24] <daf> SteveA: I'm not sure how to go about https://launchpad.net/products/launchpad/+bug/30959
[12:24] <Ubugtu> malone bug 30959 in launchpad "+sources/something should redirect to +source/something" [Normal,Confirmed]  
[12:25] <SteveA> daf: not a big deal, i think
[12:25] <daf> no, it's matter of cutting down needless NotFoundErrors
[12:25] <daf> not important, but I thought it would be a quick fix
[12:25] <SteveA> assign it to me
[12:25] <daf> ok, thanks
[12:25] <mpt> That's something I need to learn
[12:26] <daf> mpt: ?
[12:26] <mpt> How to set up 302s, 410s, and so on for various URL schemes
[12:26] <daf> grep for @redirect
[12:26] <daf> that takes care of 3xx codes
[12:27] <daf> we don't have infrastructure for 410 yet
[12:27] <mpt> ok
[12:27] <BjornT> jamesh: any chance of getting a review of my branch that is in your queue soon? it's the oldest branch non-reviewed branch on PendingReviews, and the diff is small.
[12:27] <SteveA> remind me what 410 is
[12:28] <daf> Gone, IIRC
[12:28] <mpt> yes
[12:33] <iwj> Thanks.
[12:35] <SteveA> stub: https://launchpad.net/bugs/3204/+text
[12:35] <Ubugtu> malone bug 3204 in flashplugin-nonfree "Font missing after breezy upgrade !" [Normal,Fix released]  
[12:35] <SteveA> https://launchpad.net/products/launchpad/+bugs-text
[12:53] <carlos> kiko: hi
[12:53] <carlos> kiko: I have a fix for #1681 with tests done
[12:54] <carlos> kiko: I'm going to develop a migration script to fix our production data
[12:54] <daf> carlos: kiko hasn't shown himself yet today
[12:54] <carlos> oh
[12:54] <carlos> ok
[12:55] <daf> are you looking for a review?
[12:55] <carlos> daf, SteveA: Should I ask for a review and merge the fix now and request a cherry pick while I develop and test the migration script?
[12:55] <carlos> the fix will not break with current broken DB data
[12:55] <daf> then that sounds ok
[12:56] <carlos> ok
[12:59] <jbailey> stub: Around?
[12:59] <jbailey> stub: Tollef said the he seems to have wound up with evo-exchange bugs, so I think something went wrong in the query.
[01:00] <Mithrandir> stub: 14942, 14944 being two of the bugs that I shouldn't have gotten
[01:02] <dilys> Merge to devel/launchpad/: switch PGP code to use pygpgme instead of pyme, r=SteveA (r3155: James Henstridge)
[01:06] <SteveA> carlos: i think we'll wait for tuesday's rollout, seeing as the merge didn't apply nicely
[01:06] <carlos> SteveA: This one is another bug fix
[01:07] <daf> even so, I'm not sure it's worth rolling it out before Tuesday
[01:07] <carlos> SteveA: about that other failure, I can try to solve the errors
[01:07] <daf> I think your time would be better spent on the Dapper imports
[01:07] <SteveA> i'm confused as to exactly which errors we're talking aobut
[01:08] <SteveA> but i think getting things fixed so that they can be rolled out at the start of next week is the best policy
[01:08] <SteveA> we can also get them onto staging as soon as they're in RF
[01:08] <SteveA> so that we can get some people to try the features out on staging too
[01:08] <carlos> SteveA: stub was not able to cherry pick the revision for the +translate form because he got errors
[01:08] <daf> "errors" == "test failures"
[01:09] <carlos> daf: yes
[01:09] <carlos> sorry
[01:09] <carlos> SteveA: if it's on rocketfuel, if we rollout HEAD it should work
[01:09] <SteveA> ok
[01:09] <carlos> so staging should have the fix already
[01:09] <SteveA> so, stu knows the revision ids
[01:09] <carlos> with today's source update
[01:09] <SteveA> matsubara: can you test this stuff on staging?
[01:10] <daf> testing the fix for #1681 on staging would be good
[01:10] <carlos> 1681 is not yet on staging
[01:10] <daf> right
[01:10] <SteveA> if it is in RF, we can ask stu to do a code-update on staging
[01:10] <carlos> we have the SELECT COUNTs on staging
[01:10] <daf> it is not in RF yet
[01:10] <carlos> SteveA: I need first a review
[01:10] <SteveA> ok, so that's what to aim for
[01:10] <carlos> pushing it atm
[01:10] <SteveA> review -> RF -> staging -> tuesday -> rollout
[01:11] <SteveA> with some manual testing on staging
[01:11] <daf> concisely put
[01:12] <stub> I've kicked off a staging update
[01:13] <daf> carlos: what do you think the right fix is for https://launchpad.net/products/rosetta/+bug/31381
[01:13] <Ubugtu> malone bug 31381 in rosetta "POMsgSet.active_texts assumes POFile.pluralforms is an int" [Normal,Unconfirmed]  
[01:13] <matsubara> SteveA: test bug 1681 on staging, is that right? I wasn't following the discussion...
[01:13] <Ubugtu> malone bug 1681 in rosetta "Viewing a translation page fails in unix2newlines" [Major,In progress]  http://launchpad.net/bugs/1681
[01:14] <daf> carlos: just return [None]  when pluralforms is None?
[01:14] <stub> jbailey: Urgh. I didn't read my notes closely enough and assigned the evolution-exchange bugs to tollef too. I'll rerun the script to reassign them to desktop-bugs
[01:14] <SteveA> daf: would you arrange this with carlos and matsubara please?
[01:14] <daf> SteveA: yes
[01:14] <SteveA> thanks all
[01:14] <daf> matsubara: that's correct
[01:14] <jbailey> SteveA: I bounced some ideas off of stub last night re: the historical debbugs imports that are collecting dust in open states in Malone.  I'd like to propose that the tasks themselves get deleted (although the remote bug watch should be preserved) until such time as auto-sync'ing becomes possible again.  From whom would you like a "that would be a GREAT idea, Steve!" to do this?  I'll go shopping for support. =)
[01:14] <daf> matsubara: carlos is preparing a fix for review now
[01:14] <jbailey> stub: Lovely, thanks.
[01:14] <daf> carlos: please let matsubara know when your fix is rolled out on staging
[01:15] <daf> matsubara: carlos will let you know when it's ready for testing
[01:15] <matsubara> daf: ok
[01:15] <carlos> sure
[01:15] <SteveA> jbailey: mdz
[01:15] <jbailey> SteveA: Thanks!
[01:16] <carlos> daf: let me see some code first
[01:16] <daf> carlos: sure
[01:16] <SteveA> jbailey: and, if you get support, an item on the next launchpad devel meeting agenda
[01:16] <SteveA> i won't be there probably, as i'm traveling that day, but kiko will be able to take care of it
[01:16] <jbailey> SteveA: How are those submitted?
[01:17] <daf> jbailey: the MeetingAgenda page on the wiki
[01:17] <jbailey> daf: Ta.
[01:17] <stub> jbailey: fixed.
[01:18] <Mithrandir> stub: lovely, thanks.
[01:20] <carlos> daf: Hmm, well, if it's None is because we don't know plural forms, so I guess the answer is yes, return [None]  if it's None
[01:21] <daf> carlos: cook, thanks
[01:21] <daf> cool
[01:27] <SteveA> salgado: ping
[01:28] <salgado> hi SteveA 
[01:28] <SteveA> i've been looking at that bug with a duplicate name constriant that was broken
[01:29] <SteveA> i can see a place where we don't check names as properly as the database constraint does
[01:29] <SteveA> if you look in database/person.py, line 970, in getByName
[01:29] <SteveA> you can see that ignore_merged defaults to True
[01:29] <salgado> right
[01:30] <SteveA> so, it is possible that the name used matches a previously merged name
[01:30] <SteveA> and, when checking constraints using getByName, we must ensure that ignore_merge is False
[01:30] <salgado> I thought about that, but all previously merged names should have a -merged string appended
[01:30] <daf> BjornT: "should get resolved until Tuesday" -- do you perhaps mean "before Tuesday"?
[01:30] <SteveA> salgado: a query on staging or production will confirm that
[01:30] <SteveA> salgado: also, the code can be simplified:
[01:31] <SteveA>         person = Person.selectOne(query)
[01:31] <SteveA>         if person is None:
[01:31] <SteveA>             return default
[01:31] <SteveA>         return person
[01:31] <SteveA> 
[01:31] <SteveA> this can become
[01:31] <SteveA>     return Person.selectOne(query)
[01:31] <SteveA> oh
[01:31] <SteveA> that doesn't take care of the default
[01:31] <SteveA> is the default even used?
[01:31] <salgado> no, I don't think it's ever used
[01:32] <salgado> I've been dropping these 'dafault' arguments in new code I write, as I've never seen them being used
[01:32] <SteveA> it is *never* used
[01:32] <salgado> so, yes, I think this one can be dropped too
[01:32] <SteveA> so, that's a bug to file, to simplify the APIs
[01:33] <daf> salgado: "dafault" -- what happens when I'm not around? :)
[01:35] <SteveA> salgado: do you have access to staging to make that query?
[01:35] <salgado> SteveA, no
[01:35] <salgado> daf, eh?
[01:35] <SteveA> so, you'll need to ask someone to make the query
[01:35] <daf> never mind; bad pun
[01:36] <SteveA> stub: can you do a query on production or staging please?  want to find out the list of Person.name where Person.mergedID is not None, specifically, if there are any without a -merged on the end.
[01:37] <SteveA> also... i'm getting a timeout when trying to add a subscriber to a bug
[01:37] <stub> SteveA: There are two
[01:37] <SteveA> what are the names?
[01:38] <BjornT> daf: yeah, i meant before Tuesday
[01:38] <SteveA> salgado: so... need a bug for changing the constraints to use ignore_merged=False, and we should also ask stub to update these names in production, i think
[01:39] <stub> Ahh... they have the -merged1 suffix instead
[01:39] <salgado> ahhh
[01:40] <SteveA> salgado: i'm going to add the values of local variables to tracebacks in oops reports soon 
[01:40] <SteveA> and that will help a lot with diagnosing these kinds of problems
[01:40] <salgado> stub, so, all merged accounts' names have the -merged suffix?
[01:40] <stub> -merged or -merged1
[01:40] <stub> yes
[01:42] <salgado> SteveA, what do you mean by these kinds of problems?
[01:43] <SteveA> problems where we think that the code always passes through a particular point
[01:43] <SteveA> but you can't tell exactly from the traceback
[01:43] <SteveA> because the value of local variables at each point are not visible
[01:43] <SteveA> stub: is there a person with name djaghloul2008 in the db?
[01:43] <stub> SteveA: Yes
[01:44] <salgado> SteveA, but that wouldn't help in this case because we'd still need to know a value from the database
[01:44] <SteveA> salgado: i think it would help see what code paths were taken
[01:45] <SteveA> salgado: is it possible that the insert was attempted twice in the same request?
[01:47] <salgado> SteveA, what do you mean? a non-tested code path that would try to insert it twice?
[01:47] <SteveA> maybe... just an idea to try to explain the oops.  although i guess two inserts would occur in the oops in that case.
[01:48] <salgado> stub, can you check the datecreated of this djaghloul2008 account?
[01:48] <stub> 2006-02-16 11:39:26.746718
[01:48] <stub> UTC
[01:49] <salgado> 2006-02-16 11:39:45 UTC
[01:50] <salgado> and the total sql time of this request is 13003 ms
[01:50] <salgado> a reload, maybe?
[01:50] <SteveA> web logs would show it
[01:51] <SteveA> the getByName checks should still have been hit though
[01:51] <salgado> not really. most of the time spent in sql queries is in the insert
[01:51] <SteveA> weblogs would show if the user reloaded
[01:52] <SteveA> the getByName checks should still have been used in a reload
[01:52] <SteveA> to ensure we don't get the database programming error
[01:53] <salgado> right, but isn't it possible that right after the getByName() returned None, the first request finished the insert?
[01:53] <SteveA> shouldn't make any difference
[01:54] <SteveA> that would give us a Serialization error
[01:54] <SteveA> stub: we're running at that level of isolation are we not?
[01:55] <stub> We are running serialized isolation level
[01:56] <SteveA> so, the other possibility is some kind of weird sqlobject transaction breakage
[02:02] <kiko> ahoy there
[02:02] <kiko> lots of scrollback
[02:02] <kiko> carlos, nice to hear about the bugfix for 1681
[02:05] <carlos> kiko: if you want to do a review of it now....
[02:05] <kiko> I might if it's not huge
[02:06] <carlos> kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/fileWyjptj.html
[02:06] <cprov> stub: ping
[02:07] <daf> carlos: those AssertionErrors
[02:08] <daf> carlos: perhaps pass the msgid/text into AssertionError with the error message?
[02:09] <daf> carlos: in fact, I suggest:
[02:09] <carlos> daf: do you think it's useful?. I added it to be sure that we don't get mixed values
[02:09] <daf> class NewlineStype: UNIX = 0; WINDOWS = 1; MAC = 2
[02:09] <kiko> salgado, help me understand -- what is the deal with py.test? why is it not yet required? when will it become?
[02:09] <carlos> if we get those assertions, we need to update that method
[02:09] <daf> msgid_style = NewLineStyle.UNIX
[02:09] <daf> then you can do:
[02:09] <daf> if (text_style != msgid_style):
[02:09] <daf> much simpler code
[02:10] <kiko> looks nice
[02:10] <salgado> kiko, it'll become a launchpad dependency as soon as we have a working package in breezy, or when we change to dapper. whatever comes first
[02:10] <kiko> salgado, what uses it?
[02:10] <daf> carlos: if we get those assertions, it might be nice to know which combination is occurring
[02:10] <salgado> kiko, sqlobject's tests
[02:11] <kiko> salgado, and we don't run those tests today?
[02:11] <salgado> no, we don't
[02:11] <carlos> daf: ok
[02:11] <kiko> I see
[02:11] <kiko> and you want to activate them, right, salgado?
[02:12] <salgado> exactly. I fixed the tests for the code where we diverge from upstream and packaged the codespeak-lib package
[02:12] <salgado> but the first package was broken
[02:12] <carlos> daf: with your NEwLineStyle class, how would I know if there are more than one style at the same time?
[02:12] <carlos> daf: if you want to remove all those boolean vars....
[02:14] <Alinux> hello all, I can't enter into https://launchpad.net/distros/ubuntu/dapper/+source/gnome-panel/+pots/gnome-panel-2.0/ka/+translate    I get timeout error message all the time :/
[02:14] <daf> carlos: ah, I see
[02:14] <Alinux> OOPS-48D229
[02:14] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/48D229
[02:15] <daf> carlos: wait a second, though
[02:15] <carlos> ok
[02:15] <daf> ah, never mind
[02:15] <carlos> oh, cool, Ubugtu knows about oops!
[02:16] <carlos> Alinux: let me check
[02:16] <daf> carlos: maybe msgid/text_has_*_style would be clearer variable names
[02:17] <Alinux> I would like to update some translations :D
[02:17] <daf> carlos: I'd still like a way to make this simpler
[02:17] <carlos> daf: any suggestion is welcomed
[02:18] <Alinux> I've tried with Mozilla and Epiphany to connect this lauchpad page.
[02:18] <carlos> Alinux: We are working on those timeouts
[02:18] <daf> carlos: I have an idea: has_{mac,unix,windows}_newline()
[02:18] <Alinux> carlos, ok
[02:18] <carlos> Alinux: it's not a problem with your browser
[02:18] <Alinux> grazie muchas :)
[02:18] <daf> carlos: text_has_windows_style = has_windows_newline(text)
[02:19] <Alinux> carlos, ok then, I simply collaborate :) 
[02:19] <daf> carlos: that would eliminate the stripped_{text,msgid} locals
[02:19] <kiko> SteveA, it would probably make sense for matsubara to test gpg stuff it we want to roll it out.
[02:19] <SteveA> kiko: yeah
[02:19] <carlos> daf: so you want three new methods to remove two variables?
[02:20] <kiko> unfortunately for us, staging does not send out email :-(
[02:20] <carlos> daf: I'm not quite sure it's a good change...
[02:20] <SteveA> we can configure staging to send mail somewhere
[02:20] <SteveA> like, an account on the canonical imap server
[02:20] <carlos> daf: in fact, if has_windows_newline is true, mac and unix ones will be true tooo
[02:20] <salgado> SteveA, so, do you have a plan for that issue with the account creation? maybe you want me to try and find what's going on?
[02:21] <carlos> daf: that's the point behind the stripped... vars
[02:21] <Alinux> is there big differencies between Ubuntu's gnome-panel and GNOME's gnome-panel ?
[02:21] <daf> carlos: right, you moved the stripped_ vars into the functions
[02:21] <carlos> Alinux: not really, a couple of string additions
[02:21] <carlos> daf: what will we win then?
[02:21] <daf> carlos: it's just that this is a big method and I find it hard to read
[02:21] <Alinux> carlos, ok.
[02:21] <carlos> daf: the function is not so long to justify that split ...
[02:22] <daf> 44 lines is a long function
[02:22] <carlos> daf: sure, but your changes are not going to reduce the code but the initialization part
[02:22] <SteveA> salgado: i don't have a plan right now.  it remains a mystery.  can you add an extra assert in _newPerson that getByName(name) is None ?
[02:23] <SteveA> salgado: and also change the occurrances of getByName such as that one to include merged ?
[02:23] <SteveA> i'll spend a bit of time today improving oops output, and so if this happens again, we'll be in a better position to see what is going on
[02:23] <salgado> SteveA, sure, I'll do that
[02:24] <daf> carlos: shrug; I'm not the reviewer
[02:24] <SteveA> matsubara: the user you were giving help to yesterday uploading a gpg key eventually managed to do it.  it seems the reboot of the keyserver machine did something to make it work...
[02:25] <SteveA> anyway, he was grateful for the help!
[02:25] <matsubara> SteveA: cool
[02:28] <kiko> daf, is o-b-t on track or does it need help?
[02:29] <daf> I've just merged RF to fix a conflict; then I'll push
[02:31] <kiko> cool.
[02:49] <matsubara> I can't run any tests. I'm getting ConfigurationError: ('Invalid value for', 'factory', "Couldn't import canonical.launchpad.utilities, No module named gpgme") . What do I need to update to get things working again?
[02:50] <kiko> wow
[02:50] <kiko> matsubara, did you update your sourcecode without updating your tree, or vice-versa?
[02:50] <salgado> matsubara, I think you're missing a make or make build
[02:52] <kiko> daf, check out salgado's bug 31650 -- a new oops we have never seen before.
[02:52] <kiko> BjornT, could you look into it?
[02:52] <matsubara> kiko, salgado: updated both the sourcecode and my tree, rsynced to our prebuilt tree and did the make build 
[02:53] <matsubara> am I missing anything else?
[02:53] <SteveA> kiko: is chinstrap reachable by you?
[02:54] <SteveA> i can reach it now
[02:55] <kiko> I don't think I understand what you mean by "rsynced to our prebuilt tree"
[02:55] <kiko> matsubara, do you mean the same as "updated sourcecode"?
[02:56] <matsubara> kiko: yep
[02:56] <kiko> did you bzr merge?
[02:56] <matsubara> kiko: yep
[02:58] <kiko> then it's odd.
[02:59] <matsubara> $ bzr st
[02:59] <matsubara> unknown:
[02:59] <matsubara>   sourcecode/pyme
[02:59] <matsubara> is this normal?
[03:00] <BjornT> kiko: well, how much do you want me to look into it? i can see that the message got inserted correctly into the db, but somehow new_bug.messages doesn't include the inserted message.
[03:00] <kiko> rm -rf sourcecode/pyme
[03:01] <kiko> BjornT, invest 10 minutes?
[03:02] <BjornT> kiko: ok
[03:02] <matsubara> kiko: that was on the prebuilt tree...
[03:02] <kiko> matsubara, yeah, I believe that directory is lost.
[03:05] <matsubara> kiko: didn't solve the problem. Is there anything else that I can do?
[03:05] <kiko> yes. bzr merge. no code should use gpgme any longer.
[03:06] <salgado> isn't gpgme the name of the new module and pyme the name of the old one?
[03:06] <kiko> it's pygpgme I think
[03:06] <kiko> but maybe you're right
[03:06] <kiko> matsubara, do you have sourcecode/gpgme?
[03:07] <matsubara> nope
[03:08] <kiko> is the prebuilt tree fucked?
[03:08] <matsubara> yes
[03:08] <salgado> probably
[03:08] <kiko> great!
[03:08] <kiko> matsubara, you'll neet to get gpgme directly
[03:09] <kiko> whoa
[03:09] <kiko> rocketfuel/pypgpme is empty
[03:09] <kiko> how did this merge?
[03:09] <kiko> oh, never mind me
[03:10] <kiko> matsubara, /home/warthogs/archives/rocketfuel/pygpgme
[03:10] <kiko> that's what you want
[03:10] <kiko> matsubara, you could convince salgado to bzr get it into the right place in the prebuilt tree
[03:10] <kiko> he is usually easy to convince of such hacks
[03:10] <matsubara> salgado: ^^
[03:11] <SteveA> daf, matsubara, kiko: see https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-02-07/D314
[03:11] <SteveA> new oops layout
[03:11] <salgado> that was not convincing at all
[03:12] <matsubara> salgado: and where is the 'camaradagem'?
[03:12] <kiko> yes, camaradagem is essential in our quest
[03:12] <kiko> SteveA, that's great! long queries are > 2ms?
[03:13] <SteveA> no
[03:13] <SteveA> just top 5
[03:13] <kiko> SteveA, ah, I see.
[03:13] <SteveA> but, what do you think would be best there?
[03:13] <kiko> say that somewhere? :-)
[03:14] <kiko> 5 longest-running queries?
[03:14] <kiko> I think that's fine
[03:14] <SteveA> i mean, is that the most useful thing to present?
[03:14] <SteveA> okay
[03:14] <kiko> yeah, it makes it easy to focus
[03:14] <SteveA> i'll change the heading then
[03:16] <kiko> SteveA, some other suggestions:
[03:16] <kiko> a) you could place the (top) link on the same line as the heading, in a <small> or something, to avoid making more use of vertical space
[03:17] <kiko> b) i'd place the treceback before request variables
[03:17] <kiko> c) I'd place the HTTP method in the summary at the very top of the oops (before Exception type even)
[03:17] <kiko> the HTTP method is very important and yet very hidden
[03:17] <SteveA> kiko: to (a), everything in the report has appropriate html elements and css classes.  I'll leave it to mpt to provide a stylesheet.
[03:18] <SteveA> to (b) ok
[03:18] <SteveA> to (c) okay
[03:18] <kiko> d) I'd make the URL be a link to the actual URL
[03:18] <kiko> e) I'd make the user be a link to the actual user's page in lp
[03:18] <kiko> this is great work, congratulations
[03:20] <kiko> salgado, don't forget to remind stub to set up the expiration cronjob on tuesday
[03:21] <kiko> carlos, have a new diff?
[03:23] <carlos> kiko: no, I'm not completely sure I should do the changes daf suggested.
[03:23] <kiko> daf?
[03:30] <BjornT> kiko: i couldn't find exactly what caused bug 31650, someone with more db and sqlobject knowledge should have look at it. i've added a comment to the bug, though.
[03:30] <Ubugtu> malone bug 31650 in launchpad "OOPS When filing a bug on launchpad" [Normal,Confirmed]  http://launchpad.net/bugs/31650
[03:30] <kiko> thanks BjornT -- who should be the assignee?
[03:32] <BjornT> kiko: hmm, not sure. SteveA would probably be a good candidate to take a look at it if he has time.
[03:33] <kiko> BjornT, do you know why we have bugtasks method on our bugtargets? they are so error-prone...
[03:33] <dilys> Merge to devel/launchpad/: r=bradb Fix for bug 6697: Source package bugs list is missing filter links. Makes the filter links portlet (on the RHS) available in distro source package and distrorelease source package pages; removes the redundant link to advanced search; also cleans up lint here and there (r3156: kiko)
[03:33] <kiko> yes!
[03:34] <salgado> bradb, is this (^) one that fix for the Advanced button not doing anything?
[03:34] <kiko> salgado, is there such a bug?!
[03:34] <kiko> BjornT, stub perhaps?
[03:34] <salgado> there was at least. but only on the +bugs page. all others work fine
[03:35] <BjornT> kiko: which bugtasks methods are you referring to?
[03:35] <matsubara> kiko: bug 30690
[03:35] <kiko> salgado, can you try and reproduce and give me a link? if it exists I need to fix it right away
[03:35] <Ubugtu> malone bug 30690 in malone "'Advanced...' button on bugs listing doesn't do anything" [Normal,Confirmed]  http://launchpad.net/bugs/30690
[03:35] <SteveA> kiko: done b, c, d and e
[03:35] <kiko> thanks SteveA -- can I test?
[03:35] <SteveA> sure
[03:35] <kiko> matsubara, I'll look into it, because I just removed the other link to that page!
[03:35] <BjornT> kiko: yes, stub could take a look at it
[03:35] <SteveA> it is there, as jamesh's oops.cgi
[03:35] <salgado> kiko, bradb had a fix for that, but last I heard he had problems when merging it
[03:36] <kiko> BjornT, assign it, and thanks
[03:36] <kiko> SteveA, there's a bug:
[03:36] <kiko> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-02-17/C30
[03:37] <kiko> look at the User link
[03:37] <SteveA> interesting
[03:37] <SteveA> it means that oops reports don't have that data
[03:37] <SteveA> they have only the internal user id, not the name
[03:38] <kiko> pity. ok, undo that.
[03:38] <SteveA> is there a URL in launchpad where i can map Person.id to person page?
[03:38] <bradb> salgado: That fix is irrelevant now, because the advanced search is (very) temporarily gone.
[03:38] <kiko> salgado might know that, salgado
[03:38] <kiko> bradb, what did you just say?
[03:38] <kiko> salgado might know that, SteveA 
[03:38] <kiko> bradb, IOW your branch removes advanced search?
[03:39] <salgado> AFAIK we don't expose Person.id anywhere
[03:39] <bradb> kiko: Yeah. But there are still links for 90% of what people do.
[03:39] <bradb> e.g. open, critical, unassigned, unconfirmed, etc.
[03:39] <kiko> bradb, why? I don't remember us discussing that, ever.
[03:41] <bradb> kiko: The existing search widgets don't fit in the new layout.
[03:42] <bradb> kiko: You can see that advanced search is not part of the bug contact reports. It says "(Advanced search coming soon)"
[03:42] <kiko> don't fit?
[03:43] <SteveA> kiko, salgado: we should store the user.name in the request / launchbag or somewhere, so that an oops report can use it
[03:43] <kiko> the launchbag has the user object, I don't get what you mean.
[03:43] <bradb> kiko: They'd need some HTML-fu to look acceptable in the new layout.
[03:43] <kiko> bradb, why not just keep them, even with poor layout?
[03:43] <salgado> launchbag.user.name?
[03:44] <SteveA> the point is to ensure we're not getting any *new* data when we generate an oops report
[03:44] <SteveA> it is possible that an oops report is made when we don't actually have a user object, or something like that
[03:44] <kiko> I see what you mean
[03:44] <bradb> kiko: Sure. I could do that before I land that branch.
[03:44] <SteveA> anyway, i'll look into it
[03:44] <kiko> mmmm
[03:44] <SteveA> and merge it
[03:44] <kiko> thanks SteveA 
[03:44] <SteveA> i have other changes to make to oopses
[03:45] <kiko> you are an oopser
[03:55] <salgado> fastest lunch ever
[03:57] <kiko> you are the doc holliday of lunches
[04:06] <SteveA> kiko: i'm landing a change that will make the Person.name appear in oops reports.  I'll update the script next week, after the rollout.  But, of course, we'll get bad links for some old oops reports.
[04:06] <kiko> cool -- that's fine
[04:13] <salgado> cprov, should we start that review today?
[04:14] <cprov> salgado: I'm still working on soyuz production release tests, can't really do both
[04:15] <kiko> but salgado can start looking at the branch
[04:15] <cprov> salgado: kiko: yes, he can 
[04:15] <salgado> does that means you're still adding code on that branch?
[04:18] <salgado> if so, it'll be the second time I'm going to review a work that's still in progress, and that will require me to read the whole diff again when it's finished
[04:18] <salgado> cprov, ^
[04:22] <cprov> salgado: yes. what shall I do ? we can't block dapper release because we can't manage to review the code at time
[04:22] <cprov> salgado: it's no your fault, I know, neither mine 
[04:23] <kiko> cprov, mmm, what are you saying? we should make time for reviewing and landing the branch, asap.
[04:23] <salgado> instead of adding more features
[04:25] <cprov> kiko: salgado: if you say so and if we can continue w/o -updates uploads , let's do it 
[04:25] <kiko> cprov, depends on how long you think that will take to complete.
[04:25] <kiko> we can manage, but we need some idea of the situation first..
[04:26] <slomo> hi... would it be possible to subscribe "motu" to all bugs on packages in universe? currently we have to do this by hand for every bug and i guess this could be done automatically ;)
[04:26] <cprov> kiko: it was exaustly described last days, I've done the code for it but it requires real world test, I'm doing them in mawson at moment, rebuild a proper archive
[04:27] <kiko> cprov, we can wait, then. if you want to tell salgado where he can start, where you won't be changing it...
[04:27] <kiko> slomo, what do you use motu for?
[04:28] <kiko> the team.
[04:28] <cprov> kiko: good idea
[04:29] <jbailey> https://launchpad.net/distros/ubuntu/+bug/31775 - It looks like Mark magically subscribed people by adding things at the bottom of the bug.  Am I confused?  And if not, is bug magic like this documented somewhere? =)
[04:29] <Ubugtu> malone bug 31775 in Ubuntu "Ubuntu should have better links to support options" [Normal,Unconfirmed]  
[04:29] <jbailey> Ubugtu: Thanks.
[04:29] <cprov> salgado: you can review changes under lib/canonical/archivepublisher and in lib/canonical/database
[04:29] <kiko> jbailey, it's just the email interface -- see the wiki doc.
[04:29] <jbailey> kiko: Ah, so it's not something I can do from the webform?
[04:30] <jbailey> I've never used the email interface.
[04:31] <slomo> kiko: it is in general a team with all MOTU but in no relation to the ubuntu-dev team so main devs don't get bug mails for universe stuff for example. currently it's used mostly for having all bugs in universe send to a central mailinglist thus everybody notices them and maybe works on them. also it's used for motu internal votes, etc
[04:31] <kiko> slomo, why don't you use ubuntu-bugs for that?
[04:31] <kiko> slomo, you can procmail filter on the component in the bug task lines
[04:34] <dholbach> hello
[04:34] <slomo> hi dholbach 
[04:34] <dholbach> is setting the default subscriber for universe packages a problem?
[04:36] <bradb> dholbach: What do you mean, exactly? You can subscribe yourself to a universe package. Someone else can subscribe to that package too.
[04:37] <dholbach> slomo was just in a discussion about it, no?
[04:39] <elmo> ddaa: around?
[04:47] <bradb> Hm, chinstrap down/
[04:47] <bradb> ?
[04:47] <dholbach> bradb: #canonical
[04:48] <bradb> right, woo
[04:50] <bradb> matsubara: Did you manage to get your tree working?
[04:51] <kiko> it's prebuilt that is broken, bradb 
[04:51] <bradb> kiko: I don't think so
[04:51] <bradb> bradb@chinstrap /home/warthogs/archives/rocketfuel $ ls pygpgme/devel/
[04:51] <bradb> bradb@chinstrap /home/warthogs/archives/rocketfuel $ 
[04:51] <kiko> bradb, is there a .bzr  in there?
[04:51] <matsubara> bradb: yep
[04:51] <salgado> it has only the .bzr directory
[04:51] <cprov> salgado: one idea, my soyuz-production branch is frozen since 14th, I can continue with uploader-tests until the next release, hope we can manage to review it during this time-window. it's not the best, but it is what I can do to help you.
[04:51] <kiko> that is fine
[04:51] <salgado> that's all that's needed
[04:51] <bradb> oh, ok
[04:54] <salgado> cprov, I don't understand what you mean. does the features you have in your soyuz-production branch replace the features in the uploader-tests branch?
[04:54] <ddaa> elmo: pong
[04:54] <salgado> I don't see why landing the former would make it less necessary to land the latter
[04:55] <elmo> ddaa: I recommend you don't restart marambio job-of-death till the whole power polava is sorted
[04:55] <cprov> salgado: no uploader-test was merged in soyuz-production 14th and it still untouched
[04:55] <ddaa> elmo: how would I be able to tell?
[04:56] <cprov> salgado: if you don't see, nevermind ... do whatever you preffer.
[04:56] <elmo> ddaa: I'll mail you
[04:56] <ddaa> elmo: thank you
[04:57] <ddaa> note that the job would have no problem with swsusp
[04:57] <ddaa> it's all local filesystem operation
[04:58] <kiko> power polava? :)
[05:02] <salgado> cprov, have you gone through all points I made in the first review? I didn't received a reply for the second part of the review I sent
[05:03] <cprov> salgado: I've looked into it some time ago, it seems I have one pending review to send you.
[05:06] <salgado> it's very hard to re-review a patch in which the things I pointed haven't been fixed
[05:07] <cprov> salgado: yes, I've done only a small piece re-send by spiv, but not addressed all issues pointed by your take 2
[05:09] <cprov> salgado: I think ...it's #async, the complainer's paradise!... not here :(
[05:12] <salgado> okay, I'll wait for your reply then. there's not much I can do before getting it
[05:15] <cprov> salgado: okay, I'll address them when I finish the test
[05:25] <dilys> Merge to devel/launchpad/: [trivial]  Add an assert in PersonSet._newPerson to make sure the name is not already in use and don't ignore merged accounts when checking if a name is already in use on PersonSet.createPersonAndEmail(). This is to help us debugging https://launchpad.net/products/launchpad/+bug/31755 (r3157: Guilherme Salgado)
[05:50] <ddaa> kiko: re syncher-logging: yes, I think it is worth the added code, but if you disagree I'll just remove it, and add it back later when you are tired of browsing through pages of redudant backtraces for transient errors in launchpad-error-reports.
[05:50] <ddaa> kiko: so say "no" and I remove it, say "yes" and I leave it.
[05:52] <kiko> ddaa, why don't you factor your options into logger_options?
[05:52] <ddaa> ?
[05:52] <ddaa> because it has nothing to do with command line options?
[05:53] <WaterSevenUb> carlos, ubuntu-translators accepts emails from subscribed users automatically?
[05:53] <WaterSevenUb> carlos, takes a lot of time usually?
[05:55] <dilys> Merge to devel/launchpad/: [trivial]  Fix for bug 31573: Evolution source package in Ubuntu page tells me I don't have access. Makes DistributionSourcePackageView.latest_bugtasks use the right API to get the latest tasks. (r3158: kiko)
[05:56] <ddaa> kiko: though arguably I could move logException into _LogWrapper
[05:59] <carlos> WaterSevenUb: yes, subscribed users send emails directly to the mailing list
[05:59] <carlos> WaterSevenUb: non subscribed users need that I moderate it.
[05:59] <WaterSevenUb> carlos, ok, thx.
[06:02] <kiko> ddaa, I think that's what I meant!
[06:04] <ddaa> what about I adress the naming issue raised by BjornT, merge, then make a new branch? I think adding a visible method in the _LogWrapper could be a bit controversial, and that also remove the need for this ugly "logger_object" thing now that I noticed that there's actually a logger.log API....
[06:05] <kiko> ddaa, I fear that the new branch will get deprioritized by your more important work. but okay.
[06:06] <kiko> lifeless isn't around by any chance?
[06:06] <ddaa> well, I fear that going for another round of review means that the whole thing is going to be deprioritized...
[06:06] <kiko> I'm not suggesting another round of review
[06:07] <ddaa> I think it would become necessary. Moving the method to the other class would need some pervasive changes.
[06:07] <kiko> really?!
[06:07] <ddaa> yeah, I'm not using the wrapper object at all
[06:07] <kiko> mmmm
[06:07] <ddaa> also it's not clear that it should become a translucent wrapper...
[06:07] <kiko> I don't like the sound of this...
[06:08] <ddaa> anyhow, time for lunch
[06:08] <ddaa> I do not care about arguing over this sort of cosmetic change.
[06:13] <stratus> SteveA: hi, shouldn't launchpad return a www-authenticate header due to that basic authentication scheme you told me two days ago?
[06:15] <kiko> stratus, it /should/ yes
[06:15] <kiko> have you had no luck?
[06:15] <stratus> kiko: maybe i'm missing something but i can't see the www-authenticate header here.
[06:15] <stratus> kiko: try wget --no-check-certificate -S https://launchpad.net/+login
[06:16] <daf> Launchpad does not send authentication headers
[06:16] <daf> but it does accept them
[06:16] <daf> hi stratus 
[06:16] <daf> you asked me for some code, but then you left IRC
[06:16] <stratus> hi daf
[06:16] <stratus> oh, thanks daf
[06:16] <stratus> i was looking for the realm
[06:16] <stratus> so, do you have the code?
[06:16] <daf> I'll paste it now
[06:17] <stratus> thanks
[06:17] <kiko> daf, have you managed to bzr branch pygpgme?
[06:17] <kiko> bzr doesn't like me
[06:19] <kiko> seb128, bug 31573 fixed in PQM.
[06:19] <Ubugtu> malone bug 31573 in launchpad "Evolution source package in Ubuntu page tells me I don't have access" [Normal,Fix committed]  http://launchpad.net/bugs/31573
[06:19] <daf> kiko: I haven't tred
[06:19] <daf> kiko: I haven't tried
[06:20] <kiko> daf, if you update your rocketfuel, prepare to die!
[06:20] <daf> ok, I won't do that
[06:20] <kiko> shouldn't this work?
[06:20] <daf> stratus: http://muse.19inch.net/~daf/misc/lp_auth
[06:20] <kiko> $ bzr get sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/pygpgme/devel
[06:20] <kiko> bzr: ERROR: Not a branch: sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/pygpgme/devel
[06:20] <kiko> Killed by signal 1.
[06:20] <daf> stratus: this is ripped out of a program I have; you might need to hack it to work
[06:21] <kiko> the prebuilt tree is a bit like a landmine
[06:21] <stratus> daf: oh, i see. thanks! should i consider that gpl code?
[06:21] <daf> stratus: good question
[06:22] <daf> kiko: do you have an answer to that?
[06:22] <kiko> daf, stratus: I think it's reasonable to release that into the public domain, put it in the wiki.
[06:22] <daf> ok
[06:22] <daf> page name?
[06:22] <stratus> sounds good, thanks
[06:22] <kiko> no questions allowed
[06:23] <kiko> daf, BasicLaunchpadClient? 
[06:23] <kiko> wth is wrong with my bzr get
[06:24] <daf> https://wiki.launchpad.canonical.com/LaunchpadAutomation
[06:24] <kiko> fine
[06:24] <daf> dunno, looks fine to me
[06:24] <daf> hmm
[06:25] <kiko> fuck this, I'm rsyncing
[06:26] <daf> maybe an extra slash after the host
[06:26] <kiko> nope.
[06:26] <daf> odd, it's hanging here
[06:26] <salgado> kiko, you can rsync and then bzr revert it
[06:26] <kiko> I'm doing it now
[06:26] <salgado> somebody once told that should work
[06:26] <kiko> since you didn't do it
[06:26] <kiko> and now I am blocked 
[06:27] <salgado> bzr get failed for me too
[06:27] <kiko> I want to kill the attendant that sold me bad rocketfuel 
[06:27] <daf> bzr get doesn't have an --overwrite, sadly
[06:27] <daf> bzr get sftp://chinstrap.ubuntu.com//home/warthogs/archives/rocketfuel/pygpgme/devel works for me
[06:27] <kiko> I DON"T WANT TO HEAR THAT
[06:28] <daf> (daf@olwen:~) bzr --version
[06:28] <daf> bzr (bazaar-ng) 0.8pre
[06:28] <kiko> salgado, actually, you /need/ to do ti
[06:28] <kiko> because I don't have perms to write there
[06:28] <daf> Branched 46 revision(s).
[06:28] <kiko> oh never mind
[06:28] <kiko> have it your way
[06:29] <dilys> Merge to devel/launchpad/: Fix https://launchpad.net/products/launchpad/+bug/31198 (update-pkgcache raising TypeError exception) r=kiko (r3159: Diogo Matsubara)
[06:29] <kiko> at least dilys loves me
[06:30] <dilys> camaradagem, kiko
[06:31] <kiko> WTF is up
[06:31] <kiko> AMAZING
[06:32] <kiko> it works
[06:33] <kiko> dilys, we should hire you to manage rocketfuel
[06:33] <kiko> my soyuz would never have crashed if you were in charge
[06:33] <kiko> man this new strokes album is excellent
[06:33] <kiko> mmmm mmmmmm mmmmmmmmm mm 
[06:37] <kiko> salgado, matsubara: rocketfuel is fixed. you will need to re-run link-external-sourcecode
[06:47] <carlos> cprov: hi, how's going the soyuz testing? is it ready?
[06:49] <cprov> carlos: re-publishing a fresh archive, might take some time, to you have a set of packages to upload ?
[06:49] <carlos> cprov: I want to try the pmount package we already use in our tests
[06:49] <carlos> and anyone from universe
[06:50] <carlos> cprov: do you need anything special or just a package from dapper is enough?
[06:52] <cprov> carlos: the perfect organization is a directory containing another directory with a single upload as rosetta/upload-1/[foo.changes, foo.orig.tar.gz, foo.diff]  
[06:52] <carlos> ok
[06:52] <carlos> cprov: I will prepare that on mawson
[06:52] <cprov> carlos: sweet
[06:52] <carlos> but I'm leaving soon
[06:53] <carlos> cprov: when will that be imported?
[06:53] <cprov> carlos: tonight or tomorrow, I can send you the complete output when it's done
[06:54] <carlos> cprov: will mawson have all the information in place until Monday?
[06:54] <carlos> I want to check the content of the translation import queue
[06:54] <cprov> carlos: possibly yes
[06:54] <carlos> ok
[06:54] <carlos> cool
[07:09] <kiko> matsubara, please include a description of /what/ you changed when fixing a bug in your commit and merge messages
[07:12] <matsubara> kiko: ok
[07:12] <kiko> bradb, I was thinking of fixing bug 30690, but I guess you can do it, and avoid further conflicts?
[07:12] <Ubugtu> malone bug 30690 in malone "'Advanced...' button on bugs listing doesn't do anything" [Normal,Confirmed]  http://launchpad.net/bugs/30690
[07:13] <kiko> carlos, daf: no agreement on bug 1681? what do I do?
[07:13] <Ubugtu> malone bug 1681 in rosetta "Viewing a translation page fails in unix2newlines" [Major,In progress]  http://launchpad.net/bugs/1681
[07:13] <bradb> kiko: Yeah, that's the plan.
[07:13] <kiko> okay, I'll assign
[07:13] <kiko> thanks
[07:19] <carlos> kiko: Well, daf's solution is not bad, it's just another way to do it, If you, as a reviewer, think that the suggested changes could clarify a bit more the code, I don't have any issue to do that change. It's just that under my point of view I don't think those changes will increase the quality of the code (but I could be wrong there)
[07:19] <kiko> what did he suggest, carlos, exactly? guide me through the diff
[07:20] <carlos> I also agree that the code is not perfect and I'm open to any suggestion to improve it
[07:20] <kiko> if he suggested something that will add sanity to normalizeNewLines, I am +1 on it
[07:21] <carlos> well, from what I saw, the changes are related only to the initialization of the method, it implies creating three new functions and the body of the method will not change
[07:22] <carlos> kiko: I don't think it's a big improvement, it's just another way to do that. The main problem is with the body
[07:24] <kiko> carlos, I think I have a suggestion. hold on.
[07:24] <carlos> kiko: ok
[07:24] <carlos> thanks
[07:25] <kiko> okay.
[07:25] <kiko> how about this
[07:25] <kiko> let's use two variables
[07:25] <kiko> msgid_style
[07:25] <kiko> and text_style
[07:26] <kiko> mmmm
[07:26] <kiko> no, let's not.
[07:26] <kiko> carlos, what was daf's suggestion?
[07:26] <dilys> Merge to devel/launchpad/: [r=stub]  DB patch removing 2 unused columns from Build table and fixed on dogfood configuration. (r3160: Celso Providelo)
[07:27] <carlos> kiko: there is a good optimization that daf already did but it implies that the Assert checks cannot be done
[07:27] <kiko> so here's a question
[07:27] <carlos> I mean, another suggestions
[07:27] <carlos> let me look for daf's comments and will paste it to you...
[07:27] <kiko> if msgid_in_windows_style, then msgid_in_mac_style is always true.
[07:27] <kiko> same for text_*
[07:27] <kiko> oh, stripped.
[07:27] <kiko> sorry
[07:27] <carlos> kiko: ;-)
[07:28] <ddaa> niemeyer: ping
[07:28] <niemeyer> ddaa: Pong
[07:28] <ddaa> niemeyer: who is responsible for the ProductSeries web pages now?
[07:28] <kiko> carlos, so, let me understand: only ONE of text_*_style and msgid_*_style will be true in a certain moment?
[07:28] <kiko> or can be true
[07:29] <ddaa> (as in "understand what the various bits are for, and interactions with various subsystems")
[07:29] <kiko> ddaa, nobody in particular, and particularly not niemeyer -- it's launchapd.
[07:29] <niemeyer> ddaa: I don't know..
[07:29] <ddaa> niemeyer: do you know what ProductSeries.branch is for?
[07:30] <ddaa> niemeyer: is that used by Dyson or Sourcerer?
[07:30] <daf> carlos: yeah, that big if at the end is the main thing
[07:30] <ddaa> (or some other guy in that clan)
[07:30] <daf> carlos: perhaps you could do something like:
[07:30] <niemeyer> ddaa: For Sourcerer, I don't think so.. for Dyson, I have no idea.
[07:30] <kiko> daf, carlos: I think I am having an idea.
[07:31] <daf> text_lines = re.split('r\?\n?', text)
[07:31] <ddaa> mh...
[07:31] <carlos> kiko: right, I'm assuming that's the case. But I'm adding the Assertions to protect us from real world data. If they appear, we will need to handle those cases too
[07:31] <daf> '\r\n'.join(text_lines) / '\r'.join(text_lines) / '\n'.join(text_lines)
[07:31] <ddaa> it does not seem critical then...
[07:31] <kiko> carlos, that's fine, I just wanted to make sure that was true.
[07:31] <niemeyer> ddaa: Is it something strange at all? I mean, it looks natural to have a branch attached to a ProductSeries..
[07:31] <ddaa> niemeyer: currently when you set ProductSeries.branch, the ProductSeries page will OOPS.
[07:32] <ddaa> Which shows that it's not tested, and I also think it was never used before.
[07:33] <niemeyer> ddaa: It probably was used at some point, but given that it was just for informational purposes, it's probably rotting..
[07:33] <ddaa> niemeyer: I think we'll want to get that bug fixed as part of the importd transition ot importd, so we can set ProductSeries.branch properly. So I was trying to figure out whether there was some hidden dependency to be aware of.
[07:33] <carlos> daf: I don't understand the split regexpression
[07:33] <daf> carlos: split on \n, \r, or \r\n
[07:34] <carlos> daf: but we have tests so if it's able to split the lines correctly being them with '\r'  or '\n' or '\r\n', that's fine
[07:34] <daf> carlos: at least, that's what it's supposed to do :)
[07:34] <ddaa> niemeyer: otherwise, I'll just consider it's purely a Launchpad display issue and ask some random devel to fix it in any way that appears reasonable. Probably jamesh, but maybe somebody else.
[07:34] <daf> it reads "maybe a carriage return followed by maybe a newline"
[07:34] <daf> actually, that doesn't work
[07:34] <daf> because it matches the empty string
[07:35] <niemeyer> ddaa: Sourcerer is what moves information about an existing package into a HCT understandable form.. It does make sense to have some linkage between that and a ProductSeries.. but it can't be done automatically, I'm afraid.
[07:35] <daf> re.split('(?:\r|\n|\r\n)', text), perhaps
[07:35] <niemeyer> ddaa: Keybuk certainly knows that a lot better than I do..
[07:35] <ddaa> Well, since Keybuk is now distro team, I thought that you were the guy to aks about that sort of stuff.
[07:36] <niemeyer> ddaa: Well.. I'm on another team as well, if that's what's preventing you from talking to him. :)
[07:36] <carlos> kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/filebYzqmw.html <- This is the log for the chat we had this morning
[07:36] <carlos> kiko: What do you think?
[07:36] <ddaa> niemeyer: well, I'm also not too good at communication with Keybuk. But I'll ask him.
[07:36] <ddaa> Keybuk: ping?
[07:36] <niemeyer> ddaa: But I don't see any problem in talking about that with you, for that matter.
[07:36] <carlos> daf: I suppose that a comment before that split call would be enough
[07:36] <kiko> carlos, I was suggesting exactly what daf was
[07:37] <carlos> daf: so the reader can know what the hell does that reg expression
[07:37] <kiko> except using a string instead of a class
[07:37] <daf> carlos: :)
[07:37] <kiko> carlos, note that you can still do the assertions
[07:37] <carlos> kiko: but you lose the assertions
[07:37] <carlos> kiko: how?
[07:37] <kiko> no
[07:37] <Keybuk> ddaa: yo, 'sup?
[07:37] <kiko> msgid_style = None
[07:37] <niemeyer> ddaa: Notice that, in any case, you can probably do whatever you want at that stage.
[07:37] <daf> kiko: problem is, each string can be in multiple styles
[07:37] <kiko> daf, it can't really -- we just need to assert.
[07:37] <niemeyer> ddaa: Keybuk will have to figure out a lot of stuff when making HCT working with Launchpad again.
[07:37] <ddaa> Keybuk: Setting ProductSeries.branch to something causes the ProductSeries +index page to OOPS.
[07:37] <carlos> daf: well, they shouldn't, that's why we use Assertions instead of handling those cases
[07:37] <niemeyer> s/working/work/
[07:38] <Keybuk> ddaa: ok ...
[07:38] <niemeyer> Keybuk: Heya.. regards from the south hemispehere..
[07:38] <ddaa> Keybuk: is there some dependency to be aware of to fix that, or can that be considered purely a Launchpad display issue?
[07:38] <carlos> kiko: ok, so we have an extra status that means 'more than one style'?
[07:38] <Keybuk> niemeyer: that's kinda why we stopped trying to keep HCT "up to date" with Launchpad, it's much easier just to wait for Launchpad to be ready, and then bring HCT up to date once; instead of doing it every week and still having nothing to show for it :(
[07:39] <kiko> carlos, if that happens, we just blow up
[07:39] <ddaa> Keybuk: okay, you just answered my question, thank you.
[07:39] <Keybuk> ddaa: hmm... the ProductSeries.branch thing was a Markism for the "main trunk of the product series development branch in CVS, which might not be the MAIN trunk" or something
[07:39] <Keybuk> wasn't it
[07:39] <kiko> carlos,  so we do something like:
[07:39] <carlos> kiko: oh, directly raise the exception. Ok
[07:39] <niemeyer> Keybuk: Yeah, apologies for bothering you before. bzr is currently a mutant beast.
[07:39] <kiko> right
[07:39] <kiko> msgid_style = None
[07:39] <kiko> if XXX:
[07:39] <kiko>     assert msgid_style is None
[07:40] <kiko>     msgid_style = XXX
[07:40] <ddaa> Keybuk: well dunno really. At the moment there's a clear use for it, associate a branch to RCS import.
[07:40] <Keybuk> ddaa: that's my memory of what that's for, yes
[07:40] <Keybuk> it's definitely related to RCS imports
[07:40] <carlos> kiko: I prefer to use the class that daf suggested then
[07:40] <carlos> with the approach you are talking about now
[07:40] <ddaa> Keybuk: okay, so basically I get to decided what it's for.
[07:40] <Keybuk> yup, I think so
[07:40] <carlos> daf, kiko: is that ok for you?
[07:41] <ddaa> Keybuk: cool, thank you.
[07:41] <kiko> carlos, I guess, let's see it
[07:41] <daf> carlos: I'm confused; show me the code :)
[07:41] <carlos> ok
[07:47] <kiko> bradb, BjornT: ping?
[07:47] <bradb> kiko: pong
[07:48] <kiko> bradb, shouldn't Milestone.bugtasks be nuked? it is error-prone in the sense it doesn't consider privacy.
[07:48] <Kinnison> ciau all
[07:49] <bradb> I didn't know that existed. Yeah, it should probably be nuked.
[07:49] <kiko> bradb, I'm trying to nuke out all the bugtasks multiplejoins
[07:49] <kiko> I might have to make them into properties if that fails
[07:50] <kiko> properties should be easy
[07:50] <bradb> ISTR there being a bug about perms denied when viewing bugs on a milestone, so that's probably what's causing it.
[07:50] <kiko> yeah.
[07:50] <kiko> it's silly
[07:50] <kiko> let's see what PQM says
[07:51] <ddaa> experiment-driven development :)
[07:51] <daf> trial-and-PQM-failure
[07:51] <ddaa> Actually, would be kinda neat to have a PQM that does not actually commit.
[07:52] <ddaa> So we could use it as a test farm as we go, and be pretty confident that the merge would pass when we go for review.
[07:52] <daf> that would be nice
[07:52] <daf> PQM seems to run tests faster than I can
[07:52] <bradb> As long as there's no queue...
[07:52] <salgado> it'd be nice to have jamesh's script run the test for us
[07:52] <zyga> carlos: hello, how is development doing? :-)
[07:53] <ddaa> daf: it has a fast 64 system all for itself.
[07:53] <salgado> so the reviewers could look there and see how many tests failed
[07:53] <ddaa> * 64 bits
[07:53] <carlos> zyga: fine, thanks. This week is being really productive ;-)
[07:53] <daf> salgado: oh, nice idea
[07:53] <ddaa> actually, no failure should be a prerequisite for most reviews...
[07:54] <kiko> ddaa++
[07:54] <ddaa> fixing them ofter requires non-trivial changes.
[07:54] <salgado> if a test fails your branch is kicked out from the review queue
[07:54] <zyga> carlos: I'm *so* out of sync due to my day job but I'm glad to know things are going well
[07:54] <kiko> pqm.ubuntu.com has been fucked for a while now...
[07:54] <daf> salgado: or at least pushed to the back :)
[07:55] <carlos> zyga: well, they could be better... :-P
[07:56] <daf> carlos: dude, you've been making them better all week
[07:57] <carlos> daf: I know, but I need to be back to my productivity of last year...
[07:57] <carlos> ;-)
[07:57] <zyga> carlos: I second daf's opinion
[07:57] <carlos> it was better
[07:57] <kiko> daf, matsubara: can you confirm my comment in bug 31583?
[07:57] <Ubugtu> malone bug 31583 in launchpad "linux-image appears in popup summary, cannot file bug against it" [Normal,Unconfirmed]  http://launchpad.net/bugs/31583
[07:57] <zyga> carlos: don't burn out!
[07:58] <kiko> bradb, are you considering working on bug 3683? otherwise, I'll get it done
[07:58] <Ubugtu> malone bug 3683 in malone "Input validation error reported, but problem not indicated" [Normal,Confirmed]  http://launchpad.net/bugs/3683
[07:58] <daf> kiko: looks likely
[07:59] <bradb> kiko: Probably better to hand off to you, if you're up for it.
[07:59] <kiko> daf, dupe away
[08:18] <carlos> kiko: changing the AssertionError with an assert breaks the tests 
[08:19] <carlos> kiko: and I'm not able to make it pass, I don't understand what happens... the output is the same..
[08:19] <carlos> any hint?
[08:21] <kiko> carlos, I would need to see the code, I don't have a crystal ball
[08:21] <kiko> and the error output
[08:22] <carlos> kiko: sorry O:-)
[08:23] <carlos> kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/fileOikCVh.html
[08:24] <carlos> kiko: the assertion tests are the ones failing
[08:24] <bradb> kiko: Hmph, this package bug contact changing turns out to be really annoying in this model. Before unsubscribing the previous contact, I have to check that, among other things, this contact isn't a package bug contact for any of the other packages on which this bug is filed.
[08:25] <kiko> bradb, you don't need to unsubscribe.
[08:25] <kiko> I never suggested that
[08:26] <kiko> or maybe I have, but I am pretty sure you don't need to implement that right now.
[08:26] <bradb> Leaving the previous contact subscribed would just annoy that user.
[08:26] <kiko> bradb, just leave him subscribed, and allow people to unsubscribe others, and you're fine.
[08:26] <kiko> the latter still needs to be implemented, btw.
[08:26] <bradb> kiko: And, of course, unsubscribing others is a whole can of worms unto itself. :)
[08:26] <kiko> I think it's fine, actually
[08:26] <kiko> but anyway
[08:27] <kiko> I am pretty sure you shouldn't consider unsubscribing.
[08:27] <kiko> just subscribing
[08:27] <kiko> at least for now -- cheap and easy.
[08:27] <bradb> Cheap and easy to implement, but I have a strong hunch it's just a pain for the user.
[08:27] <bradb> I'll ask in #canonical.
[08:27] <kiko> no, I think it'll be fine.
[08:28] <kiko> bradb, go ahead and do it.
[08:28] <kiko> you can unsubscribe later
[08:28] <kiko> even offer an intelligent UI to allow optionally doing it
[08:29] <kiko> You are retargetting this task from Launchpad to Ubuntu. [ ]  Unsubscribe bug contact for Launchpad
[08:29] <kiko> or something in the lines.
[08:29] <kiko> carlos, what are the errors?
[08:30] <bradb> kiko: It would still be more work, and easy for the user to make a mistake, I think.
[08:30] <carlos> kiko: the test checks that we raise the assertions
[08:30] <bradb> Because they're not going to bother verifying that the user is a contact on any other package for that bug first.
[08:30] <carlos> kiko: but the test fails
[08:30] <carlos> let me show the output
[08:32] <carlos> kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/fileXm2HnJ.html
[08:32] <kiko> carlos, it seems the tests don't like assertions
[08:32] <kiko> use a specific exception then
[08:33] <carlos> ok
[08:36] <carlos> kiko: still failing :-?
[08:36] <kiko> that's odd.
[08:43] <carlos> kiko: anyway, could you review it and approve/reject it? I will try to merge it and if pqm rejects it too, I will try to fix it on Monday
[08:43] <carlos> I need to leave...
[08:43] <kiko> carlos, PQM will reject if it the test fails, it's very simple.
[08:44] <carlos> kiko: I know, but perhaps is something weird in my computer
[08:44] <carlos> there are other tests checking it that way
[08:44] <kiko> unlikely
[08:44] <kiko> but you are not giving me enough information..
[08:44] <carlos> and it was working this morning....
[08:44] <kiko> you were doing raise AssertionError
[08:44] <carlos> kiko: I gave you the test, the code and the output....
[08:44] <kiko> that's different
[08:44] <kiko> I told you to change the exception for your own
[08:44] <carlos> kiko: I changed it back to raise AssertionError
[08:45] <carlos> and still fails
 I told you to change the exception for your own
[08:45] <kiko> MismatchedLineFeedError or soemthing
[08:45] <carlos> oh, to another one?
[08:45] <kiko> right
[08:46] <carlos> ok
[08:52] <cprov> carlos: send me an email when you place your uploads in mawson, ok ? I'll be here tomorrow, see you
[08:52] <carlos> cprov: sure, sorry for the delay. Thank you
[08:53] <carlos> kiko: same problem
[08:53] <cprov> carlos: it's not a blocker, mawson still publishing the archive.
[08:53] <carlos> ok
[08:53] <kiko> what does "same problem" mean?
[08:53] <carlos> kiko: with the concrete exception the test is still failing
[08:53] <kiko> you still get assertion errors?
[08:53] <kiko> if so, then you're definitely doing something wrong :-)
[08:54] <carlos> kiko: I'm not able to see anything... I need to stop now. Could you bless that patch with the condition to get that part of the test fixed?
[08:55] <kiko> no.
[08:55] <carlos> ok, then, let's continue it on Monday, ok?
[08:55] <kiko> sure.
[08:55] <carlos> night dudes
[08:55] <carlos> see you!
[08:55] <carlos> kiko: and thanks for your input
[08:57] <kiko> thanks
[09:25] <kiko> lifeless, heads up for the rf-built bustage
[09:26] <lifeless> kiko: thanks
[09:26] <lifeless> kiko: will check in a sec.
[09:27] <lifeless> it should have added it itself after 30 minutes
[09:27] <kiko> yeah, it's odd.
[09:27] <kiko> but no worries
[09:30] <mdz> kiko: so jbailey has raised the same issue that I did, about the noise generated by all of these old bugs which don't apply to Ubuntu but which still have open tasks in Debian
[09:30] <mdz> kiko: his proposed solution is to delete the watches, but I'm not too keen on throwing away that information. how do you think we can address this problem?
[09:30] <kiko> yep
[09:31] <kiko> we should allow filtering on that view
[09:31] <jbailey> mdz: I'd like to see them still tracked as a remote bug watch.
[09:31] <kiko> to say "only view ubuntu tasks"
[09:31] <jbailey> mdz: But I don't think there's much value in keeping the tasks open - it doesn't give us any information.
[09:31] <mdz> I thought the tasks and the watches were coupled
[09:31] <jbailey> mdz: Lemme check.  I think when I open a watch on the gnome bug tracker or the gcc one, it doesn't get a task.
[09:32] <mdz> kiko: is that a little bit of work or a lot of work?
[09:32] <kiko> not a lot of work if we get the filtering stuff done as bradb wants it
[09:32] <jbailey> Oh, hmm, no I'm wrong.
[09:32] <jbailey> https://launchpad.net/distros/ubuntu/+source/gnome-games/+bug/29690
[09:32] <Ubugtu> malone bug 29690 in gnome-games "Freecell fails to work on platforms where qthreads is not available" [Normal,Unconfirmed]  
[09:34] <lifeless> ah
[09:34] <bradb> mdz: noise where? bugmail? some URL?
[09:34] <lifeless> I know why
[09:35] <bradb> I'm guessing you're meaning the personal reports
[09:35] <bradb> (except the package bug contacts report)
[09:35] <jbailey> bradb: When you subscribe to a bug, any open task causes it to appear in the list.
[09:35] <lifeless> fixed
[09:35] <lifeless> kiko: ^^
[09:35] <kiko> lifeless, is the man
[09:35] <jbailey> bradb: So that means any upstream watches, etc. cause the bug to never go away.
[09:36] <bradb> jbailey: right. that's a problem on the reported bugs, subscribed, and assigned bugs reports.
[09:38] <bradb> actually, not a problem on the assigned one
[09:38] <bradb> jbailey: I guess you work a lot with the subscribed bugs report, right?
[09:40] <jbailey> bradb: Right - some of it's from a support perspective to keep track of things that might be interesting, so of it is from a core libraries/system hacker point of view where I might follow a bug to see if it's something I need to help on.
[09:41] <jbailey> And some things annoy my wife and I follow them to make sure that I know when they'll be fixed =P
[09:41] <bradb> heh
[09:43] <bradb> Like kiko says, I think our filter criteria display (shown in the package bug reports) can be improved to make that more useful. Planned to work on at the London sprint, I think.
[10:07] <kiko-zzz> right, right
[10:07] <kiko-zzz> birthday dinner tonight
[10:07] <kiko-zzz> keep those oops tight
[10:07] <kiko-zzz> and see you in the morning light
[10:07] <bradb> have fun
[10:23] <ddaa> Yay, first candidate plan for import transition: https://chinstrap.warthogs.hbd.com/~david/importd-bzr-plan/importd-bzr-plan.html#implementation-plan
[10:23] <ddaa> I knew I had forgot a few bits the first time :)
[10:26] <Kamion> Can anyone investigate why https://launchpad.net/distros/ubuntu/+source/espresso/0.99.14 isn't building on anything but i386?
[10:26] <Kamion> I urgently need those builds for Flight CD 4 preparation
[10:26] <bradb> Kinnison?
[10:27] <bradb> If not, maybe SteveA or kiko-zzz can find someone quickly.
[10:33] <Kamion> also, if somebody could investigate why the upload of ltsp 0.75 processed at 20:50 UTC today failed with an exception during accept (see #canonical), Edubuntu Flight CD 4 would be very grateful
[10:33] <Kamion> ogra's trying a reupload though
[10:35] <bradb> Kamion: Can you email kiko, cprov, and Kinnison about that issue?
[10:36] <Kamion> the latter issue is no longer a problem, because a reupload worked
[10:36] <Kamion> I'll file a bug
[10:36] <bradb> ok, thanks
[10:42] <Oublieuse> Bonsoir
[10:42] <Oublieuse> Hello
[10:43] <Oublieuse> I'd like to add a team for breton translaotors on launchapd
[10:43] <Oublieuse> how to do this?
[10:44] <Kamion> bradb: (mailed kiko, cprov, and Kinnison about the stuck build, though; thanks)
[10:45] <bradb> no prob
[10:45] <Oublieuse> can somebody answer me?
[10:45] <jbailey> Oublieuse: It looks like you should email rosetta@ubuntu.com
[10:46] <bradb> Oublieuse: J'ai ta rponse: https://launchpad.net/people/+newteam
[10:46] <Oublieuse> ok
[10:46] <Oublieuse> thanks
[10:46] <Oublieuse> merci bradb 
[10:46] <Oublieuse> :)
[10:46] <bradb> bienvenue
[10:46] <Oublieuse> j'ai cherch dans la faq... mais y avait juste le canal irc ;)
[10:46] <bradb> Ouais. Faut travailler l-dessus.
[10:47] <jbailey> bradb: Est-ce les quipes marche pour Rosetta?
[10:47] <jbailey> bradb: Je croyait que c'tait pour autre choses.
[10:48] <bradb> jbailey: Yar.
[10:48] <bradb> "...or the editor of a package for a particular language."
[10:48] <jbailey> bradb: Le FAQ https://wiki.ubuntu.com/RosettaFAQ indique qu'il fait envoyer un couriel.
[10:48] <Oublieuse> lol vous parlez tous franais... j'ai cru que c'tait un canal en anglais vu que launchpad est en anglais
[10:48] <Oublieuse> :D
[10:48] <bradb> Oublieuse: We just happen to live in Montral :P
[10:49] <Oublieuse> ok
[10:49] <Oublieuse> :)
[10:50] <bradb> Oublieuse: There's probably some extra work to make a team the "official" translators for some language, which carlos_ or daf could help clarify.
[10:51] <carlos_> Oublieuse: you need to create the team and after that, request it to be set as the official one at rosetta@ubuntu.com
[10:51] <Oublieuse> ok
[10:51] <Oublieuse> but I can-'t create it, they tell me I don't have de rights for it
[10:51] <Oublieuse> (and sorry for my mistakes :p )
[10:55] <bradb> Oublieuse: What's the exact error message?
[10:56] <Oublieuse> bradb> Not allowed here
[10:56] <Oublieuse> Sorry, you don't have permission to access this page.
[10:57] <carlos> Oublieuse: URL?
[10:57] <SteveA> hi Kamion.  How's it going?
[10:57] <Oublieuse> https://launchpad.net/rosetta/groups/ubuntu-translators/+appoint
[10:57] <carlos> Oublieuse: that's for admins
[10:57] <Oublieuse> ah ok
[10:57] <Oublieuse> :D
[10:57] <carlos> Oublieuse: you need to create a team at https://launchpad.net/people/
[10:58] <Oublieuse> ok
[10:58] <Oublieuse> thank you!
[10:58] <carlos> then send us the team name and the language you want to handle to the email address I just gave you
[10:58] <carlos> and we will do it for you
[11:07] <Oublieuse> done
[11:09] <Kinnison> bradb: yes?
[11:10] <bradb> Kamion had an urgent build issue that I thought you might know more about.
[11:11] <bradb> Kamion: Can anyone investigate why https://launchpad.net/distros/ubuntu/+source/espresso/0.99.14 isn't building on anything but i386?
[11:11] <bradb> [4:28pm]  Kamion: I urgently need those builds for Flight CD 4 preparation
[11:13] <Kinnison> yes, it's all working now
[11:13] <Kinnison> thanks
[11:14] <bradb> cool
[11:15] <Kinnison> If someone had rung me I'd have been able to help more
[11:25] <jblack> stub: ping
[11:30] <ddaa> wow bunch of security updates
[11:31] <ddaa> are these built with Launchpad?
[11:31] <ddaa> "MOMMY MOMMY! Soyuz eated my previous upload!! MOMMYYYYY!!!!!"
[11:32] <ddaa> yeah, apparently so :)
[11:38] <Kinnison> ddaa: No, the security updates are not currently built in launchpad