[12:14] <kiko> aha
[12:24] <lifeless> who speaks german here ?
[12:24] <bradb> is rince.africaninspace.com not used for the MLs anymore?
[12:24] <lifeless> bradb: shouldn't be
[12:24] <lifeless> bradb: it was full
[12:24] <lifeless> http://bazaar.canonical.com/ichliebees <- what does this say
[12:26] <ddaa> *giggle*
[12:27] <ddaa> real hardcore users is something canonical gaves me exposure to, and I'm grateful for it :)
[12:27] <bradb> lifeless: should i resent my mail to @lists.u.c then, or is rince going to be fixed?
[12:27] <lifeless> bradb: all the lists are named on lists.u.c or lists.c.c
[12:28] <lifeless> bradb: I have 0 context about what you are doing. so ..
[12:28] <lifeless> ddaa: ?
[12:28] <ddaa> "Hi Sandy, greetings to New Delhi, how is the weather there? Is this something like Wikipedia? What is it supposed to be?"
[12:29] <ddaa> "Hell(o) (t)here is anybody out there? Tell me where you are, what you are and what is expected to do."
[12:29] <lifeless> ddaa: do me a favour ? answer in German and say what it is ;0
[12:30] <bradb> lifeless: i sent mail to launchpad@rince.a.c earlier, but i'm getting deliver delayed messages back...wondering if i should resend to @lists.u.c or wait, on the assumption that rince is actually going to be fixed.
[12:30] <ddaa> I do not think I can possibly cast an answer that would make sense to users at that level of total cluelessness...
[12:31] <bradb> salgado: did your merge request fail?
[12:31] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: New PersonNameField (to be used in auto-generated forms), which checks if a name is not in use before trying to assign it to someone. r=SteveA (patch-2093: guilherme.salgado@canonical.com)
[12:31] <bradb> heh
[12:31] <salgado> bradb, ^^ there's your answer. :)
[12:31] <ddaa> First one: "That is my first side. Welcomely in my virtual world. Shortly more. Hopefully." Apparently he thinks that's something like geocities...
[12:31] <salgado> bradb, now is your turn. ;)
[12:32] <bradb> yup
[12:32] <bradb> i can feel the stress building alreadsy
[12:32] <kiko> lol
[12:32] <bradb> s/sy/y/
[12:36] <lifeless> bradb: dunno
[12:36] <Kinnison> ciao dudes
[12:37] <bradb> later Kinnison 
[12:39] <lifeless> night
[12:39] <ddaa> lifeless: I gave a clue to that lost soul on the wiki...
[12:39] <lifeless> danke
[12:40] <ddaa> in english, sorry
[12:40] <lifeless> oh, ho
[12:40] <lifeless> np
[12:57] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=kiko]  add canonical URL for IDistroReleaseBugTask. add sample data so that existing tests are also able to test page behaviour with distro release tasks. (patch-2094: brad.bollenbach@canonical.com)
[12:57] <kiko> wooo!
[12:57] <kiko> bradb!
[01:00] <bradb> lifeless: is there any mechanism in baz to "retire" branches? of the 39 branches returned by "baz branches", i only care about 6 of them.
[01:00] <bradb> so, i don't want to see the other 33 all the time (and, in a few months from now, double those numbers)
[01:01] <lifeless> bradb: no
[01:01] <lifeless> bradb: later there will be
[01:01] <bradb> ok, fair enough
[01:03] <bradb> there doesn't appear to be a bug open on this, so i guess that's my cue
[01:03] <lifeless> not really
[01:04] <lifeless> look way back at sealing and stuff, I'm sure there is something there
[01:16] <carlos> how could I remove a row from the DB if I have a SQLObject representing that row?
[01:18] <bradb> carlos: Foo.delete(fooinstance), IIRC
[01:18] <carlos> bradb, ok, thanks
[01:18] <lifeless> fooinstaance.delete ?
[01:20] <bradb> lifeless: the inst method is named destroySelf, IIRC, which I've always found to be a not-particularly-good-way of communicating with the maintainer of the code
[01:23] <ddaa> bradb: you can use "baz rbrowse", it will not show sealed versions by default
[01:23] <ddaa> courtesy of jblack
[01:24] <jblack> rbrowse is at least partially broken.
[01:25] <jblack> I didn't put in enough tests for rbrowse and somewhere around baz 1.2 new code started screwing up.
[01:25] <ddaa> that means it needs more testing, doesn't it? ;)
[01:25] <bradb> bradb@oxygen:~ $ baz help | grep seal <= tells me how much further I'm going to get reading more into this
[01:26] <bradb> (er, forgot to paste the empty result list, but anyway)
[01:26] <jblack> New code external to rbrowse, that is. 
[01:26] <ddaa> bradb: if you are looking for info about what sealing is, look at "commit -H"
[01:26] <jblack> hiding sealed revisions is slated to go away some day anyways. Certain important people think it shouldn't be there, and done better instead. 
[01:26] <ddaa> bazically, it's creating a "version-0" revision.
[01:27] <ddaa> jblack: I totally agree with that assessment, but that's an effective workaround in the meantime.
[01:27] <jblack> bradb: How about this:  "baz hid <archive|cat|branch|version>" 
[01:27] <ddaa> well... at least that's _a_ workaround...
[01:27] <bradb> "commit -H" and "seal" do not compute to me, but maybe this is because there's some background i don't have that other baz developers do with "sealing"
[01:28] <jblack> hide, that is.
[01:28] <jblack> Actually, I really like that. THen local rules apply. 
[01:28] <bradb> seems interesting
[01:29] <ddaa> why not... but that hiding should really be a global information.
[01:29] <bradb> it's your guys' call as to whether a "hide" option fits the Baz Way
[01:29] <jblack> No, not global. 
[01:29] <jblack> What I want to hide from my view you do not necessarily want to hide from your view. 
[01:29] <jblack> As an end user, I might not care about microbranches. As a developer, you may not care about really old stable branches (most of the time). 
[01:29] <ddaa> local fixes the "my archive is full of cruft" use case, but not the "his archive is full of cruft" one, and they are basically the same.
[01:30] <jblack> Sure it does. 
[01:30] <lifeless> seal actuall has different semantics
[01:30] <ddaa> sure it has
[01:30] <lifeless> it won't be translated into 'hidden' when we get the replacement do-it-right stuff that we're designing in bzr
[01:30] <jblack> "baz hide  <all but something>" 
[01:30] <dilys> Merge to rocketfuel@canonical.com/sqlobject--test--0.6: [trivial]  Make transactions obsolete on commit, now that the tests pass. (patch-30: andrew.bennetts@canonical.com)
[01:30] <bradb> baz hide-archive? baz unhide-archive?</brainstorm>
[01:30] <ddaa> but these semantics are ill-placed and nobody uses them.
[01:31] <jblack> That's very useful to most people. 
[01:31] <bradb> er, not archive, sorry
[01:31] <bradb> i wonder if "hide" is to generic a name though
[01:31] <jblack> Oh, Actually, a lot of people do depend upon the hide semantics of sealing. It was rather popular for baz.
[01:31] <jblack> "show" is more clear, but I shudder at "show hide <some pattern" 
[01:32] <bradb> hide-branch, show-branch? baz branch --hide? *shrug*
[01:32] <ddaa> yup... that's the only thing sealing is used for in the wild AFAIK, original sealing semantics has been classified as "looked like a good idea at the time" for about as long as I have been using arch.
[01:33] <lifeless> uhm
[01:33] <lifeless> I know branches doing both
[01:33] <jblack> "baz branch --hide" doesnt work for third parties. For the user to tell us they want to hide a branch, they have to tell us they want to branch. 
[01:34] <bradb> right
[01:34] <jblack> I personally think "baz hide PATTERNGLOB" and "baz hide /REGEX/" would do the trick neatly. 
[01:34] <bradb> i think hide or hide-branch seem ok
[01:34] <lifeless> uhm
[01:34] <jblack> It would cover future namespace plans well. 
[01:34] <lifeless> so n bzr land you jsut delete the branch
[01:34] <jblack> bradb: Were you suggesting this for bzr? 
[01:34] <lifeless> with shared storage this just unlinks the tip, it doesn't destroy history
[01:35] <bradb> jblack: no, for baz.
[01:35] <lifeless> jblack: we need to consider bzr-baz convergence in design
[01:35] <jblack> lifeless, do you have plans for tip hiding in baz? 
[01:35] <jblack> in the next 1-2 quarters? 
[01:36] <lifeless> jblack: yes
[01:37] <lifeless> in the next 2 quarters we shuold be fully converged
[01:37] <jblack> brb. I need to pick up my jaw.
[01:38] <jblack> Just to be clear, a quarter in au is the same as in the US? 3 months? 
[01:38] <lifeless> yes
[01:38] <jblack> and you do mean full convergance? 
[01:39] <jblack> what with conferences, sprints, imports, pybaz, the supermirror included? 
[01:40] <jblack> (supermirror as pertains to lp integration)
[01:41] <jblack> I'm not arguing here. If you say we can do it, then lets try and do it. 
[01:42] <lifeless> we're slated for a 1.0 release of bzr before the end of the year
[01:42] <lifeless> thats defined as bzr and baz working on the same data formats with the same (or close enough) ui, PLUS bzr 1.0 status in its own right.
[01:42] <bradb> right, well, i'm off for now. later all.
[01:44] <jblack> I hear you. 
[01:44] <jblack> Its getting close to 20:00. Somebody over here has been asking me if I've been getting hungry for the last 3 hours, so I figure its time to do something about it. 
[01:46] <jblack> <wow. compatibility in 2 months after bzr 1.0 though>
[01:46] <jblack> see you guys tomorrow morning
[01:49] <carlos> jblack, night
[01:53] <ddaa> lifeless: ArchiveLocation support mostly done, still missing bells and whistles like Archive.make_all_mirrorer, deprecation, and proper bound namespace support, but the essentials are here. That's a good time to have a look at it if you wish. I'll put it in regular review pipe when it's done.
[01:53] <lifeless> ddaa: is it good enough to migrate the importd code ?
[01:53] <ddaa> ddaa@ddaa.net--2004/pybaz--archivelocation--0
[01:53] <lifeless> ddaa: cause thats the point we switch horses and do that
[01:54] <ddaa> I think it is. I added some transitional methods because I needed _some_ bound namespace functionality for tests, and I think I covered the subset that is needed by importd.
[01:55] <lifeless> cool
[01:55] <ddaa> I would hate to merge that before doing deprecations, since I'm going to use the 1.5 opportunity to just drop _all_ the deprecated stuff.
[01:55] <lifeless> so - please put it up for review now.
[01:55] <lifeless> dude.
[01:55] <lifeless> focus on the bouncing ball here.
[01:55] <ddaa> ..
[01:56] <lifeless> we want to switch to the newer gpg logic in baz 1.4.x, that needs this code, do deprecations and dropping other things is orthogonal.
[01:56] <ddaa> also, having deprecation warnings is going to be a great help to porting the importd code.
[01:57] <ddaa> just run the test suite and a sample import run, and look for warnings
[01:59] <ddaa> lifeless: still here? That's actually the original reason for wanting deprecation warnings before review. Otherwise we risk unexpected breakage when switching to the new registration.
[02:00] <ddaa> okay... I'll do it now.
[02:01] <lifeless> ddaa: so - I'm happy whatever order you tackle it in. But goal #1 is importd running new-rego 1.4. Goal #2 is dropping old location support.
[02:02] <ddaa> adding deprecations right now
[02:02] <ddaa> I'm going to be a nice boy and _not_ fix the test suite
[02:46] <carlos> night
[04:09] <ricosuave17> what is launchpad?
[04:10] <ricosuave17> anyone here
[04:11] <lifeless> hi
[04:11] <lifeless> launchpad.ubuntu.com :)
[04:12] <ricosuave17> i read it a bit but still not sure why i just made an account
[04:13] <lifeless> its the bugtracking system, translation system, distro management, for ubuntu.
[04:13] <ricosuave17> oh what does distro management mean
[04:13] <lifeless> it integrates all these things into one environment, providing both distro specific and upstream (code author) support.
[04:13] <lifeless> distro management - what goes into the distro, packages, patches, binarys build logs etc
[04:14] <ricosuave17> interesting can i use the rosetta thing to translate text?
[04:14] <lifeless> aboslutely
[04:15] <ricosuave17> humm so im still a bit confused about everything i just installed ubuntu. i feel kind of guilty
[04:15] <lifeless> it doesn't translate for you - you translate programs by telling it what the translation should be
[04:15] <lifeless> guilty?
[04:16] <ricosuave17> yeah cause ubunutu is supposed to be a piece of discrase. they call it the windows of linux. i worked with slackware b4
[04:16] <lifeless> what does 'discrase' mean ?
[04:16] <ricosuave17> sorry i cant spell
[04:17] <ricosuave17> bad translation of spanish word to english
[04:17] <ricosuave17> it displeases thats what i got from babelfish
[04:17] <ricosuave17> well disgrace
[04:20] <ricosuave17> u still there
[04:20] <lifeless> yup
[04:20] <lifeless> doing other things too.
[04:20] <ricosuave17> oh ok
[04:20] <ricosuave17> so what is this new relaease of ubuntu. what is expected of it
[04:20] <lifeless> I hadn't heard that ubuntu was displeasing - the feedback we get is all pretty positive.
[04:21] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=bjornt]  Cronscript refactorings (patch-2095: stuart.bishop@canonical.com)
[04:21] <ricosuave17> ??
[04:23] <lifeless> ricosuave17: well breezy has a bunch of stuff in it
[04:23] <lifeless> thats the one being worked on now
[04:23] <lifeless> I don't work on the distro myself, I suggest you chat in #ubuntu if you want to talk about that
[04:23] <ricosuave17> yeah but there to many people
[04:23] <ricosuave17> do u know what cool stuff is coming in breezt
[04:24] <lifeless> thats because it is popular ;0
[04:24] <lifeless> sorry - really - #ubuntu is the right place for that
[05:05] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Trivial fixes lost in PQM (patch-2096)
[05:28] <dilys> Merge to rocketfuel@canonical.com/pygettextpo--devel--0: [r=SteveA]  add docstrings to pygettextpo (patch-6: james.henstridge@canonical.com)
[05:28] <dilys> Merge to rocketfuel@canonical.com/dists--devel--0: [trivial]  Snapshot production tree in attempt to get tests to pass (patch-96: stuart.bishop@canonical.com)
[05:54] <dilys> Merge to rocketfuel@canonical.com/launchpad--production--1.25: Cherry pick into production (patch-3: stuart.bishop@canonical.com, rocketfuel@canonical.com, celso.providelo@canonical.com ...)
[06:28] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=BjornT]  add timezone preference page (patch-2097: james.henstridge@canonical.com)
[07:18] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  use fmt:url for links in distro,release,arch details portlets (patch-2098: james.henstridge@canonical.com)
[08:34] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  fix some database imports. move Bug[Task] Delta to components. (patch-2099: bjorn.tillenius@canonical.com)
[08:59] <stub> I've just labotimized Rosetta to keep Launchpad up
[09:00] <lifeless> mmm ?
[09:01] <stub> Another lets-run-a-3-hour-query-in-our-web-application issue locking Launchpad.
[09:01] <stub> So I've revoked permissions to that table, so most of the Rosetta pages will now give a System Error.
[09:01] <lifeless> fnor
[09:01] <jamesh> what was the query for?
[09:01] <lifeless> uhm, why don't we just disable their cron job ?
[09:04] <BjornT> spiv: i've found some more problems with order by in sqlobject. 'select Foo.id, ... union select Foo.id, ... order by Foo.id' doesn't work
[09:05] <BjornT> spiv: would it be possible, for set operations, to automatically replace 'order by Foo.id' with 'order by 1'? (where 1 is the position in the select list)
[09:09] <stub> If you are pushing it too far, you don't *have* to use SQLObject. You can issue your own SQL if you like ;)
[09:10] <lifeless> stub: ew.
[09:11] <stub> lifeless: it wasn't a cron job - it was inside the launchpad application
[09:11] <lifeless> stub: oh foo
[09:11] <lifeless> stub: that really blows then huh.
[09:11] <stub> jamesh: no idea. Probably generating some percentage nobody really cares about ;)
[09:12] <lifeless> stub: could it be exporting po files for every language ?
[09:12] <stub> lifeless: That is queued and farmed out to a batch process
[09:18] <lifeless> mmm
[09:20] <lifeless> stub: do you know if elmo has done the accounts for me matching yours on the new boxen ?
[09:22] <stub> lifeless: I haven't heard back from elmo this week about anything
[09:22] <stub> Which also means the new boxes aren't active, either (launchpad is running on them, but no load balancing and no requests actually get to them)
[09:26] <lifeless> ypu
[09:26] <lifeless> yup
[09:31] <BjornT> spiv: i found another problem with you distinct fix. queries like 'SELECT DISTINCT ... FROM POTemplate, ProductSeries ... ORDER BY datecreated' fail, since datecreated exists in both tables
[09:38] <SteveA_> stub: can we add a query timeout instruction to the begin transaction stuff when starting a new sql transaction for the publisher?
[09:38] <SteveA_> that would guard against future problems with queries that take too long
[09:40] <SteveA_> stub: who is responsible for the librarian test suites?
[09:41] <lifeless> stub: spiv AFAIK
[09:56] <stub> SteveA_: Yes. I'll look into it.
[09:56] <SteveA_> ta
[09:57] <carlos> morning
[09:59] <carlos> BjornT, I think is enough if you put there POTemplate.datecreated directly
[10:08] <BjornT> carlos: yes i know. but rather than changing all queries like this in launchpad, i'd like to see it handled automatically. otherwise, depending on what you do, sometimes you have to use 'Foo.bar', and sometimes 'bar'
[10:08] <carlos> BjornT, which one should sqlobject choose ?
[10:08] <carlos> I don't see how would it be easy to decide...
[10:12] <BjornT> carlos: sourceClass._table. maybe we should enforce Foo.bar syntax, though.
[10:12] <BjornT> where is spiv?
[10:13] <carlos> BjornT, hmm, I suppose it makes sense ;-)
[10:21] <SteveA_> stub: you seem to be setting launchpad bugs to be private that do not need to be private
[10:21] <stub> Last I heard they should all be private
[10:26] <SteveA_> we've gone more public
[10:26] <SteveA_> so, bug reports that contain significant code, tracebacks, security info, etc. should be private
[10:26] <SteveA_> others can be public
[10:27] <stub> You should tell the mailing list then ;)
[10:28] <SteveA_> i'll tell people in brazil ;-)
[10:29] <BjornT> SteveA_: when i use canonical_url in a script i get: NoCanonicalUrl: No url for <Bug at 0x41889f0c> because <Bug at 0x41889f0c> broke the chain.
[10:29] <SteveA_> are canonical urls defined for bugs?
[10:29] <SteveA_> is your script running init_zopeless
[10:29] <SteveA_> ah -- i know what it is
[10:30] <SteveA_> i need to make browser:url processed by initzopeless
[10:30] <SteveA_> can you file a bug on it please?
[10:30] <SteveA_> http://en.wikipedia.org/wiki/Rosetta_(software)
[10:31] <BjornT> ok. do you think you can fix it soon? the email commands will be broken until it gets fixed.
[10:32] <SteveA_> i can give you a workaround soon
[10:33] <BjornT> cool, thanks
[10:33] <SteveA_> lib/canonical/launchpad/scripts/__init__.py, line 58
[10:34] <SteveA_>         if ns == u'http://namespaces.zope.org/browser':
[10:34] <SteveA_> change to
[10:34] <SteveA_>         if ns == u'http://namespaces.zope.org/browser' and simplename != 'url':
[10:36] <SteveA_> but, i'll need to fix this better when i land the navigation stuff
[10:37] <Kinnison> Hi guys
[10:56] <stub> SteveA_: We also need the zcml tied into the test harnesses, probably the existing Zopeless ones.
[11:32] <carlos> stub, dude, that DoS from Rosetta is a bit difficult to find with only that query...
[11:32] <carlos> stub, could you give me some extra information? (like the query executed just before that?)
[11:32] <SteveA_> do the web logs tell us what page first failed with the query?
[11:33] <carlos> not sure if that would help, but with current information is a bit difficult
[11:34] <carlos> stub, btw, I think that kind of query is only available to register users, so google should not be a problem ...
[11:35] <SteveA_> ideally, we'd add code to the dbconnection to detect that query and drop into the debugger
[11:35] <SteveA_> then carlos would run the test suite
[11:36] <carlos> SteveA_, do you have a small howto do it?
[11:37] <SteveA_> no, i just had the idea
[11:37] <SteveA_> jamesh: might have a better idea
[11:39] <SteveA_> stub, BjornT: question for you
[11:39] <SteveA_> i'm making the bug links have a title in the anchor
[11:39] <SteveA_> here's what i'm going to do:
[11:40] <SteveA_>   - if the bugnum is not found, put "no such bug" in the title, but leave the bug linked.
[11:40] <SteveA_>  - if the bugnum is found, look to see if it is private
[11:40] <SteveA_>  - if it is private, put "private bug" in the title
[11:40] <SteveA_>  - if it is not private, put the bug.title in the title.
[11:40] <SteveA_> what do you think?
[11:40] <carlos> ok. jamesh, ?
[11:42] <jamesh> carlos: there is a statement_timeout connection variable in postgres
[11:42] <carlos> stub, Do you think it's possible to get a diff between two production db? 
[11:42] <SteveA_> using the statement timeout won't help
[11:42] <carlos> jamesh, if we reduce it do you think we could know where the problem is?
[11:42] <SteveA_> carlos is trying to track down a problem that occurs with production data
[11:43] <jamesh> carlos: it can either be set in the postgresql.conf file, or using the "SET xxx TO nnn;" statement on the connection
[11:43] <SteveA_> but on his own machine
[11:43] <jamesh> carlos: it defaults to 0 (no timeout)
[11:43] <carlos> jamesh, SteveA_ is right, It makes no sense to debug it with my computer
[11:44] <jamesh> carlos: can it be reproduced on staging?
[11:44] <carlos> jamesh, the problem is that we don't know where is that query
[11:44] <carlos> as we don't have the whole query
[11:45] <jamesh> carlos: I mean, would it be possible to reproduce it on the staging server
[11:45] <jamesh> ?
[11:45] <carlos> jamesh, yes, we should be able
[11:45] <carlos> if we know where should we look at
[11:45] <jamesh> carlos: well, one option would be to set the statement_timeout to some appropriate value on staging that will catch the bad statement
[11:46] <carlos> jamesh, again, we don't know the URL that causes the bug
[11:46] <carlos> jamesh, so that will not help us too much
[11:47] <jamesh> carlos: okay.  If stub has a good idea of how long queries take on production, maybe it would be possible to set the statement_timeout there too
[11:47] <jamesh> such that it won't ever be a problem for good queries
[11:47] <jamesh> but will catch the bad rosetta queries
[11:47] <carlos> jamesh, will the users get system errors?
[11:47] <carlos> that means we would get back traces
[11:48] <carlos> and that's exactly what I need
[11:48] <jamesh> carlos: for queries that take a long time, I believe it would give an error to the user.
[11:48] <SteveA_> we need to set the timeout on the webapp publisher connection only
[11:48] <SteveA_> if we set it on scripts, it will be a problem
[11:48] <jamesh> carlos: which we record
[11:49] <jamesh> SteveA_: it is a connection variable -- the setting in postgresql.conf is just the default value
[11:49] <SteveA_> then all scripts would need to set it longer
[11:49] <SteveA_> better to set it short for the webapp.  that's the one we care most about
[11:49] <SteveA_> for avoiding DOS
[11:50] <BjornT> SteveA_: re bug linkifying. i think it sounds good. although, i think that "private bug" should only be put there if the user isn't allowed to view it.
[11:50] <jamesh> or leave it at the default of 0 for scripts, and a sane timeout for webapp
[11:50] <SteveA_> is it easy to ask "is this bug private for the logged in user" ?
[11:50] <SteveA_> jamesh: +1
[11:53] <BjornT> SteveA_: some checkPermission(bug, 'launchpad.View') should work
[11:54] <stub> carlos: https://chinstrap.ubuntu.com/~dsilvers/paste/fileGaiTs7.html
[11:54] <SteveA_> BjornT: or just try, and see if i get a Forbidden error
[11:55] <BjornT> yeah, that works as well
[11:56] <carlos> stub, I think it's related to the suggestions code
[11:56] <stub> carlos: Here is one of the full queries:
[11:56] <stub> SELECT POSubmission.id, POSubmission.origin, POSubmission.person, POSubmission.pluralform, POSubmission.datecreated, POSubmission.potranslation, POSubmission.pomsgset, POSubmission.validationstatus FROM POMsgSet, POSubmission WHERE
[11:56] <stub>                     POSubmission.pomsgset = POMsgSet.id AND
[11:56] <stub>                     POMsgSet.pofile = 1210 ORDER BY datecreated DESC LIMIT 1
[11:56] <stub> 2005-07-14 06:29:25 [10444]  LOG:  statement: SELECT COUNT(*) FROM Language, POFile WHERE
[11:56] <stub>                     POFile.potemplate = 214 AND
[11:56] <stub>                     POFile.language = Language.id AND
[11:56] <stub>                     POFile.variant IS NULL AND
[11:56] <stub>                     Language.code = 'da'
[11:56] <stub> Erm.... the first one 
[11:56] <stub> SELECT POSubmission.id, POSubmission.origin, POSubmission.person, POSubmission.pluralform, POSubmission.datecreated, POSubmission.potranslation, POSubmission.pomsgset, POSubmission.validationstatus FROM POMsgSet, POSubmission WHERE
[11:56] <carlos> cool
[11:56] <stub>                     POSubmission.pomsgset = POMsgSet.id AND
[11:56] <stub>                     POMsgSet.pofile = 1210 ORDER BY datecreated DESC LIMIT 1
[11:56] <carlos> stub, thanks
[11:57] <Kinnison> How big is POSubmission?
[11:58] <carlos> stub, hmm, the main problem is that I don't see an easy way to optimize it, the ORDER BY is the one that causes the slowness
[11:58] <jamesh> is there an index on PoSubmission.datecreated?
[11:58] <carlos> I suppose
[11:58] <carlos> Kinnison, really big
[11:58] <carlos> jamesh, does it help with an ORDER BY?
[11:58] <jamesh> carlos: it should.
[11:59] <stub> carlos: the query takes about 13 seconds, and the page appears to want to make lots of them.
[11:59] <carlos> Kinnison, I think it could be more than 4 million of rows
[11:59] <carlos> stub, I told you, suggestions
[11:59] <stub> Kinnison: A squidge under 4million at the moment
[12:00] <carlos> stub, do you think jamesh suggestion will help there?
[12:00] <carlos> could we try it?
[12:01] <carlos> I don't think we have such index
[12:01] <stub> And there are 4.8 million in pomsgset, so joining those two tables is rather dangerous and probably impractical
[12:01] <Kinnison> Does it ever get smaller?
[12:02] <jamesh> stub: the join conditions should knock most of those out pretty quickly though, right?
[12:04] <jamesh> Kinnison: POSubmission is essentially the history of all translations entered into the system
[12:05] <carlos> Kinnison, it will grow a lot
[12:05] <Kinnison> Oh christ
[12:06] <jamesh> carlos: in the sample data, EXPLAIN says that a posubmission.datecreated index would be used, and reduces the estimated minimum cost, but the max cost stayed fairly similar
[12:06] <jamesh> carlos: I don't know what the results would be like on the production data
[12:07] <carlos> stub, ?
[12:09] <stub> Most of the cost is doing the join. Two huge tables. You don't get (comparitively) many results back so the index on datecreated doesn't make much difference.
[12:09] <carlos> stub, ok, I will try to change that code to use raw queries with joins then
[12:10] <carlos> so I can filter rows before the join is performed
[12:10] <stub> I don't know if that will help - you would need to replace it with two queries on multi-million row databases.
[12:10] <carlos> not really, I have done it before and it works
[12:12] <carlos> Something like "SELECT POSubmission.* FROM POSubmission JOIN POMsgSet ON POMsgSet.id=POSubmission.pomsgset AND POMsgSet.pofile=1210"
[12:15] <jamesh> would it be difficult for the pomsgset to maintain a link to the relevant submission?
[12:17] <carlos> jamesh, we would cache too much information that way and that 'cache' should be recreated if we change the code that calculate those values
[12:18] <carlos> jamesh, if the raw sql code improves the query (I think it will do it) it should be easier, as the number of rows to join will be much lower
[12:19] <carlos> hmm, reading the query again...
[12:20] <carlos> jamesh, yes it should be easy to cache that value, as it's not part of the suggestions code but the poexport code, to know when was last time a pofile was updated so it's a matter to cache that value with every submit to that pofile...
[12:20] <jamesh> carlos: the "POMsgSet.pofile = 1210" should still be in the WHERE clause
[12:20] <carlos> jamesh, not really
[12:21] <carlos> jamesh, if we leave it in the WHERE, the join will be working with all rows
[12:21] <Kinnison> stub: What creates the users for the database?
[12:21] <jamesh> carlos: it isn't a condition used to join POSubmission and POMsgSet -- it is a condition used to filter which POMsgSet rows are used
[12:21] <carlos> adding it there we join only the rows that belong to that pofile
[12:21] <Kinnison> stub: I think we're missing some users in the dogfood db
[12:21] <stub> Kinnison: Users create the users
[12:22] <carlos> jamesh, as we will use raw queries, we can set it as %s
[12:22] <carlos> jamesh, and the python code will change it to the right value
[12:22] <carlos> as I said, I have done that before
[12:22] <Kinnison> stub: Even ones like fiera?
[12:22] <Kinnison> stub: actually I think it's a question of who is allowed to attach as that user
[12:22] <stub> Kinnison: You mean database users? They are created by security.py
[12:22] <Kinnison> is it only the launchpad user?
[12:22] <stub> Kinnison: Oh - that is a permissions thing I need to fix
[12:23] <carlos> it will be something like ... ') % sqlvalues(pofile.id)
[12:23] <jamesh> carlos: actually, according to EXPLAIN, postgres is smart enough to treat the two queries as equivalent.  But from a correctness perspective, you should put the POMsgSet.pofile=... bit in the WHERE clause
[12:24] <jamesh> stub: does using statement_timeout on production and staging sound like a sane way to catch these problems?
[12:24] <carlos> jamesh, I did that with a view, perhaps a view is different and postgresql is more stupid with those...
[12:25] <Kinnison> a view is essentially a prepared statement I thought
[12:25] <stub> Well bugger me.
[12:25] <Kinnison> Unless it's a materialised one
[12:26] <jamesh> carlos: in general, postgres optimises view usage the same as subqueries
[12:26] <stub> carlos: If you remove the limit 1, the query is much, much faster. The limit 1 is confusing the opimizer.
[12:26] <stub> jamesh: Adding the option will make pages doing bad queries return a system error instead of locking launchpad
[12:27] <jamesh> stub: which should be viewable on /errors/, right?
[12:27] <carlos> stub, I need DELETE rights for POSubmission and POTranslation from a data migration script, how could I do it? changing security.cfg seems to do nothing (and recreating the db later, of course)
[12:27] <jamesh> with stack traces
[12:27] <stub> jamesh: Yes. Might even have a useful traceback ;)
[12:27] <carlos> stub, ok, will remove the limit1 then
[12:28] <carlos> stub, the script will be run once and we will not need it anymore
[12:28] <stub> carlos: Update security.cfg, then run security.py -d mydatabase
[12:30] <SteveA_> BjornT: I can't get the attribute 'id' on a private bug.  Is this intended?
[12:30] <carlos> stub, how could I do some testing for this script with production data before you execute it?
[12:30] <stub> carlos: I run it against the staging database
[12:31] <carlos> stub, and could we get a diff against the original db? ;-)
[12:31] <stub> carlos: Sure. I'll email it to you :-P
[12:32] <SteveA_> BjornT:  the larger issue is, I cannot get a canonical_url for a private bug.  Seems wrong to me.
[12:32] <stub> Should only be a few million times
[12:33] <carlos> stub, I prefer if you call me by phone and read it :-D
[12:35] <BjornT> SteveA_: hmm. yes, getting a canonical_url should be possible. i don't think it would cause a problem to allow it. feel free to change it, if no tests break, it should be ok.
[12:36] <SteveA_> not me todya
[12:36] <SteveA_> need to do a launchpad meeting, land code, pack for brazil
[12:37] <SteveA_> i will file a bug
[12:38] <stub> carlos: If removing the limit 1 is a trivial fix, let me know what branch I can find it on and I'll cherry pick it directly (I'd rather not leave Rosetta broken over the weekend and I fly out in about 8 hours)
[12:39] <carlos> stub, will try to have it ready before the meeting 
[12:39] <carlos> it should be trivial, yes
[12:40] <carlos> but I'm trying to finish a script that I need you execute on production to migrate data that a bug that is already fixed introduced into our db
[12:42] <stub> Bugger me again. Having created and dropped the posubmission_datecreated index, the original query is working fine again :-(
[12:42] <stub> Might be a RAM thing...
[12:42] <carlos> stub, it's the export code
[12:43] <carlos> stub, so it should be enough if you just disable the cronscript that export the po files
[12:43] <stub> Hmm...  contention, or just swapping stuff out of cache
[12:43] <stub> I've regranted the permissions.
[12:47] <Kinnison> SteveA_: I'd already filed that bug
[12:47] <Kinnison> SteveA_: I've marked yours as a duplicate
[12:48] <stub> carlos: How about I make the export run daily?
[12:48] <SteveA_> Kinnison: which one?
[12:48] <SteveA_> i just filed two bugs
[12:48] <carlos> stub, thinking it twice... how is possible that the export locks launchpad?
[12:49] <Kinnison> SteveA_: the tab ordering
[12:49] <SteveA_> i don't like having a separate "malone" and "launchpad" product in launchpad
[12:49] <SteveA_> Kinnison: ta
[12:49] <carlos> stub, or did you thought it because the amount of time it takes to execute?
[12:49] <stub> It shouldn't I guess. Imports might be an issue (there appear to be three poimport jobs running at the moment...)
[12:49] <Kinnison> SteveA_: I try to file at least one bug in launchpad every day
[12:49] <Kinnison> SteveA_: as part of my community spirit
[12:49] <Kinnison> they tend to be bazaar or malone bugs :-)
[12:49] <carlos> stub, poimport can be killed, that script is broken, I have a fix ready to be merged but waiting for salgado ok
[12:50] <carlos> that's one of the changes I need you move into production today ;-)
[12:56] <stub> carlos: Better be quick. I can't do it on the plane, and I'm on the plane for a damn long time ;) Or you have to start bribing lifeless instead.
[12:57] <carlos> I suppose you will be around until the end of the meeting, right?
[12:57] <SteveA_>  /msg me meeting items.
[01:14] <SteveA_> carlos: hello
[01:14] <carlos> stub, ok, I think I have ready the script to migrate the data, how do you want to get it to test in staging and then move it to production?
[01:14] <carlos> SteveA_, hi
[01:15] <SteveA_> carlos: do you know if you or daf have done anything about these:
[01:15] <SteveA_> You should not import DummyDistroReleaseLanguage from canonical.launchpad.browser.distroreleaselanguage:
[01:15] <SteveA_>     canonical.launchpad.browser.distrorelease
[01:15] <SteveA_>     canonical.launchpad.browser.traversers
[01:15] <SteveA_> You should not import BaseExportView from canonical.launchpad.browser.pofile:
[01:15] <SteveA_>     canonical.launchpad.browser.potemplate
[01:15] <SteveA_> 
[01:15] <SteveA_>   warnings.warn(POSyntaxWarning(msg='PO file header entry has no content-type field'))
[01:15] <SteveA_>  /scratch/dists/launchpad/lib/canonical/launchpad/components/poparser.py:315: POSyntaxWarning: PO file header entry has no content-type field
[01:15] <SteveA_>   warnings.warn(POSyntaxWarning(msg='PO file header entry has no content-type field'))
[01:15] <SteveA_>  and
[01:15] <SteveA_>     No page title in canonical.launchpad.pagetitles for pofile_export
[01:16] <carlos> SteveA_, not yet, I have them in my todo list as you asked
[01:16] <carlos> but I was working on more critical things until today
[01:16] <SteveA_> ok
[01:17] <SteveA_> morgs: ping
[01:17] <morgs> SteveA_: hi
[01:17] <SteveA_> You should not import newProductRelease from canonical.launchpad.browser.productrelease:
[01:17] <SteveA_>     canonical.launchpad.browser.product
[01:17] <SteveA_>     canonical.launchpad.browser.productseries
[01:17] <stub> carlos: I'm just rebuilding staging (the db hasn't been synced with production for a few days for gina testing). Stick the script somewhere I can get it and I'll run it when it is done.
[01:17] <SteveA_> and
[01:17] <SteveA_> You should not import newBugTracker from canonical.launchpad.browser.bugtracker:    canonical.launchpad.browser.project
[01:18] <SteveA_> morgs: can you fix those please?
[01:18] <morgs> SteveA_: OK
[01:18] <SteveA_> see the mail i wrote to the list last week
[01:18] <morgs> OK
[01:19] <SteveA_>     No page title in canonical.launchpad.pagetitles for productseries_ubuntupkg
[01:19] <SteveA_> there's that too
[01:19] <carlos> stub, I'm interesting on the output of the script because there is a possible case that is not implemented because it's a bit difficult and I think that perhaps, we don't have it in our production data. If we do, then the script should show a message
[01:19] <morgs> SteveA_: OK
[01:19] <stub> carlos: ok
[01:25] <Kinnison> lifeless: how goes the new tree-format work ?
[01:25] <lifeless> Kinnison: good
[01:26] <Kinnison> lifeless: any idea when it'll make the promised performance changes? Is it still aiming for early 1.6?
[01:26] <lifeless> Kinnison: I'm working on tuning at the moment, then move to inventory-based inventorying, then apply changeset.
[01:27] <Kinnison> Will the fix for bug 212 (log-for-merge needs to be sane) come out with this?
[01:27] <Kinnison> Or is that a totally separate job?
[01:28] <lifeless> Kinnison: the fixi is trivial, fixing the damage it causes isn't
[01:28] <Kinnison> lifeless: damage?
[01:28] <lifeless> Kinnison: all the dependencies to do the fix are in place : archive version updates, tree version updates, patch versioning.
[01:28] <lifeless> Kinnison: log-for-merge, merge, merges, ancestry, annotate etc will all be affected.
[01:28] <Kinnison> oh ergh
[01:29] <lifeless> everything that says 'what patches are in this branch' has to be essentially audited
[01:30] <Kinnison> Gotcha
[01:32] <carlos> lifeless, I think pqm is stalled
[01:32] <carlos> https://chinstrap.ubuntu.com/~dsilvers/paste/fileyzlP8F.html
[01:38] <Kinnison> bradb-afk: ping
[01:44] <carlos> stub, I'm adding the script to my launchpad--devel--0 branch is that ok?
[01:45] <stub> carlos: sure
[01:45] <SteveA_>  /msg me meeting items.
[01:45] <SteveA_> meeting in 15 mins
[01:45] <SteveA_> now is a good time for a workrave
[01:45] <carlos> stub, you will need to add DELETE to security.cfg for POSubmission and POTranslation
[01:46] <SteveA_> when is dilys going to have a meeting-nanny mode?
[01:47] <Kinnison> What, to issue time warnings, collect bingo sentences, etc?
[01:49] <SteveA_> yes
[01:49] <SteveA_> and do the roll call
[01:49] <SteveA_> see and activity report call
[01:49] <SteveA_> basically, to see who has not responded to a particular question
[01:50] <mpt> Any sufficiently advanced dilys is indistinguishable from SteveA
[01:51] <carlos> stub, https://chinstrap.ubuntu.com/~dsilvers/paste/filevre5Mc.html
[01:51] <carlos> stub, that's the method that causes the problem with Rosetta
[01:51] <Kinnison> SteveA_: my understanding is that currently dilys is effectively write-only to IRC
[01:52] <SteveA_> we could modify supybot, for example
[01:52] <carlos> stub, I suppose that results[0]  is what adds there the LIMIT 1...
[01:52] <mpt> SteveA_: You had a question on DPoT while I was asleep?
[01:54] <stub> carlos: yes - that would be it. i wouldn't worry about it for now. The terrible performance happened after I added the datecreated index, but now it is gone things seem much better.
[01:54] <SteveA_> mpt: i did, but i made an executive decision on it
[01:54] <carlos> stub, should I forget it then?
[01:54] <SteveA_> mpt: there will be a merge into pqm shortly (assuming pqm is unhosed) with a new DPoT
[01:54] <SteveA_> mpt: also, what do you think about styling the DPoT text as monospaced?
[01:55] <carlos> SteveA_, your request is being processed atm
[01:55] <SteveA_> carlos: i have two
[01:55] <stub> carlos: yes. The query is fine, and I don't see a need for a workaround now. I might need to look at that table and improve its statistics so PostgreSQL doesn't choose such a bloody stupid plan though if I add the index back at some point.
[01:56] <carlos> stub, ok
[01:56] <carlos> then I have all things I need from you done
[01:56] <carlos> the production update is waiting for PQM
[01:56] <carlos> and the other is waiting for staging
[01:56] <mpt> SteveA_: I'd much prefer proportional
[01:57] <carlos> stub, I sent you an email with instructions about the migration script
[01:57] <carlos> btw
[01:58] <morgs> DPoT is also used for multiparagraph descriptions for Registry things
[01:58] <carlos> just in case you didn't know it already
[01:58] <SteveA_> carlos: there's a cut-off
[01:58] <Kinnison> M-2m
[01:58] <SteveA_> carlos: it considers 2am to be the next day
[01:58] <SteveA_> morgs: some CSS can make the font different in malone vs in registry
[01:58] <carlos> SteveA_, and it loses hours if you worked from midnight until past 2am
[01:58] <morgs> SteveA_: cool
[01:59] <bradb> morning
[01:59] <bradb> Kinnison: pong
[01:59] <carlos> as it takes the 2am entry as the beginning of the day
[01:59] <carlos> bradb, morning
[01:59] <bradb> hey carlos 
[01:59] <SteveA_> carlos: talk to mgedmin, or file a bug (somewhere)
[01:59] <Kinnison> bradb: "Bugs wot I have filed (/+reportedbugs)" -- Can that be made to hide Fixed/PendingUpload bugs?
[01:59] <morgs> gtimelog is in LP... so malone :)
[01:59] <SteveA_> carlos: mgedmin is on irc now, #pov
[02:00] <carlos> will do after the meeting
[02:00] <debonzi> carlos, I realise it somedays ago.. for somereason it is called virtual day.. 
[02:00] <carlos> SteveA_, thanks for pointing me to the author
[02:00] <SteveA_> meeting time
[02:00] <SteveA_> MEETING STARTS, wahey
[02:00] <SteveA_> who's present?
[02:00] <jamesh> me
[02:00] <morgs> me
[02:00] <BjornT> me
[02:00] <bradb> Kinnison: yeah, we need to do some thinking there
[02:00] <bradb> me
[02:00] <salgado> I am
[02:00] <jblack> me
[02:00] <stub> me
[02:00] <spiv> me
[02:00] <debonzi> me
[02:00] <lifeless> mo me
[02:00] <SteveA_> kiko will be 15 mins late, sends apologies
[02:00] <carlos> salgado, I requested a merge already so stub has time to merge my changes into production before he leaves
[02:00] <lifeless> me fi fo fum
[02:00] <Kinnison> bradb: it consistently irritates me
[02:00] <SteveA_> Keybuk won't be here, is at debconf
[02:01] <cprov> me
[02:01] <carlos> salgado, but will fix any extra comment you send to me as a later merge
[02:01] <mpt> I'm here
[02:01] <SteveA_> daf is at debconf
[02:01] <SteveA_> ddaa ?
[02:02] <SteveA_> ah, bastille day
[02:02] <SteveA_> == Agenda ==
[02:02] <SteveA_>  - roll call
[02:02] <SteveA_>  - agenda
[02:02] <SteveA_>  - activity reports
[02:02] <SteveA_>  - code quality
[02:02] <SteveA_>  - brazil
[02:02] <SteveA_>  - wiki publicly viewable, #launchpad-dev retired
[02:02] <SteveA_>  - policy for filing launchpad bugs
[02:02] <SteveA_>  - next rollouts
[02:02] <SteveA_>  - three sentences
[02:02] <SteveA_> 
[02:02] <SteveA_> any other items?
[02:02] <SteveA_>  /msg me if any come up
[02:03] <SteveA_> activity reports: who's hard-boiled and who's scrambled ?
[02:03] <SteveA_> um, who's up to date?
[02:03] <stub> me
[02:03] <morgs> The egg man...
[02:03] <morgs> me is up to date
[02:03] <spiv> I'm a day behind.
[02:03] <mpt> me!
[02:03] <jamesh> me
[02:03] <lifeless> sortof
[02:04] <SteveA_> Keybuk is behind due to mail problems from debconf
[02:04] <jblack> I'm scramled. Have data, need to present in compatible format.
[02:04] <lifeless> this week was confusing, but I have sent yesterdays in
[02:04] <mpt> well, I'm up to Tuesday, and I didn't work Wed
[02:04] <lifeless> jblack: please send in the last weeks after this meeting.
[02:04] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=salgado, trivial]  better DPoT with linkification of URLs and bugs. (patch-2100: steve.alexander@canonical.com)
[02:04] <lifeless> jblack: and ignore all previous ones.
[02:04] <SteveA_> jamesh: wel done.  you've turned your activity reporting around.
[02:05] <jblack> lifeless: I should be only a week behind. 
[02:05] <SteveA_> did anyone not speak?
[02:05] <SteveA_>  - code quality
[02:05] <SteveA_> i want to note that the code quality throughout launchpad has improved a huge amount since the sydney conference.
[02:06] <SteveA_> thank you.
[02:06] <SteveA_>  - brazil
[02:06] <SteveA_> we'll talk about this later, when kiko arrives
[02:06] <SteveA_>  - wiki publicly viewable, #launchpad-dev retired
[02:06] <SteveA_> so, we haven't used #launchpad-dev in over a week.  it is now retired.
[02:07] <Kinnison> Should we all leave it then?
[02:07] <SteveA_> don't use it any more.  i don't expect anyone to be present there.
[02:07] <SteveA_> Kinnison: yes
[02:07] <Kinnison> Okay
[02:07] <SteveA_> i would boot everyone, but that would be rude
[02:07] <SteveA_> The launchpad wiki is now publicly viewable
[02:08] <SteveA_> and has been for a week or so
[02:08] <SteveA_> so, keep this in mind when you post things there.
[02:08] <SteveA_> i don't believe anything in particular has been "censored" from it.
[02:08] <jamesh> e.g. passwords
[02:09] <carlos> jamesh, do we have passwords stored there?
[02:09] <lifeless> yes
[02:09] <SteveA_> although, i might change the STFU protocol page name, if i'm feeling prudish one day.
[02:09] <lifeless> I'd forgotten
[02:09] <carlos> ugh
[02:09] <SteveA_> we do?
[02:09] <lifeless> yes
[02:09] <lifeless> might be canonical wiki, I'll check
[02:10] <carlos> SteveA_, so we can publish that the wiki is public now? (when lifeless confirms that the passwords are not there anymore....)
[02:10] <stub> Google cache already has it if it is there
[02:10] <SteveA_> carlos: yes
[02:10] <carlos> ok, perfect
[02:10] <lifeless> carlos: no need to wait for me
[02:11] <jblack> lifeless, stevea: up to date
[02:11] <carlos> ok
[02:11] <SteveA_> any other questions about the public wiki
[02:11] <SteveA_> ?
[02:11] <carlos> SteveA_, will it be moved into ubuntu's wiki
[02:11] <SteveA_> i'll be adding a Copyright Canonical kinda footer to it, as soon as i work out how
[02:11] <carlos> or to wiki.launchpad.net?
[02:11] <morgs> While we don't have code, there are schema fragments on the wiki
[02:11] <SteveA_> carlos: not now.  we'll discuss this in brazil
[02:12] <carlos> ok
[02:12] <SteveA_> carlos: can you add that to the brazil topic page?
[02:12] <carlos> sure
[02:13] <SteveA_> morgs: it is inevitable we'll have schema fragments on the wiki, as they are an important part of our specs.
[02:13] <SteveA_> the wiki is writable only by canonical people
[02:13] <SteveA_> so, there will be no problems with defacement
[02:14] <SteveA_>  - policy for filing launchpad bugs
[02:14] <SteveA_> previously there was a policy of filing all launchpad bugs as private
[02:14] <carlos> SteveA_, done
[02:14] <SteveA_> we can relax that now, and say that if a bug could be written on the wiki, it can be marked public.
[02:15] <SteveA_> what i mean is, bugs including security vulnerabilities, code fragments, tracebacks, should be marked private still
[02:15] <carlos> so private now means more 'security' than private, right?
[02:15] <SteveA_> but all other bugs can be public
[02:15] <carlos> oh, ok
[02:15] <lifeless> SteveA_: code fragments shouldn't be a concern
[02:15] <lifeless> SteveA_: as this channel and the wiki have code
[02:15] <SteveA_> true
[02:15] <SteveA_> tracts of code then
[02:15] <Kinnison> Our "nopaste" service is currently canonical-private
[02:15] <SteveA_> entire codices
[02:16] <SteveA_> Kinnison: let's keep it that way for now
[02:16] <lifeless> SteveA_: also, having the wiki canonical-only to edit seems a little weird.
[02:16] <SteveA_> lifeless: point for discussion in brazil
[02:16] <lifeless> SteveA_: ack
[02:16] <SteveA_> hey kiko.
[02:16] <SteveA_> how's your activity reports?
[02:16] <kiko> not wonderful
[02:17] <SteveA_> moving back to...
[02:17] <SteveA_>  - brazil
[02:17] <SteveA_> kiko, give us an update
[02:17] <kiko> everything should be set up
[02:17] <kiko> 50% of the invitees have received letters of introduction
[02:17] <kiko> the other 50% will receive them today
[02:17] <kiko> you may use the letters if you feel it will help you expedite your entry in the country
[02:18] <kiko> you don't /have/ to use them
[02:18] <kiko> very funny
[02:18] <kiko> hotel and airport pickup are arranged
[02:18] <kiko> please don't change your flights from now on or you're SOL
[02:18] <kiko> (including mark)
[02:18] <kiko> what else?
[02:19] <stub> Map
[02:19] <kiko> I've put up a list of preliminary topics based on open issues I've been keeping track of
[02:19] <mpt> kiko: What do we look for when we arrive at the airport?
[02:19] <kiko> mpt, a person with a sign with your name on it
[02:19] <jamesh> a person with our name on a sign
[02:19] <mpt> oh, right
[02:19] <kiko> there will be maps of the city for everybody
[02:19] <SteveA_> kiko: do you know about the page mark put up?
[02:19] <kiko> SteveA_, BrazilTopics?
[02:19] <lifeless> jamesh: thats a sign, with a person and our name on it? or a sign with our name on it, and a separate person ?
[02:19] <SteveA_> carlos: what page did you just update?
[02:20] <stub> kiko: I mean for when I get to Sao Carlo. I'm looking for a street, but I don't know which direction or if I got off at the right spot.
[02:20] <kiko> if you'd like a map of brazil or so paulo capital the airport is a good place as any to purchase
[02:20] <jamesh> lifeless: yeah.
[02:20] <carlos> SteveA_, https://wiki.launchpad.canonical.com/BrazilTopics
[02:20] <Kinnison> kiko: Does the air port have good forrriner-accessible cash machines?
[02:20] <kiko> stub, it's likely I'll pick you up, and the wiki has directions (have you read them?) but I should be able to produce an online map
[02:20] <kiko> Kinnison, yes
[02:20] <Kinnison> kiko: good
[02:21] <stub> kiko: Look for the stinky grumpy hippy who hasn't slept for 48 hours
[02:21] <kiko> that'll be enough for a week :-P
[02:21] <Kinnison> kiko: not if they don't take a card at the bus station
[02:21] <Kinnison> kiko: or is bus-travel pre-paid?
[02:21] <SteveA_> kiko: do i look for an async person or a random person with a board?
[02:21] <kiko> Kinnison, it's not pre-paid, no. it made arrangements more complicated.
[02:21] <kiko> SteveA_, random person with sign.
[02:21] <lifeless> kiko: you say thre will be pics of the sao carlos bus station
[02:22] <kiko> lifeless, those are easy to produce, yeah.
[02:22] <lifeless> kiko: I leave in 36 hours - and others have already left. could we get them up soon ?
[02:22] <kiko> yeah
[02:22] <kiko> as I said, I'll probably pick up the first batch of forriners
[02:23] <lifeless> stub: dude, thats 4am !
[02:23] <kiko> so carlos, so carlos, so carlos? 
[02:23] <stub> lifeless: For a 6am flight
[02:23] <bradb> carlos: better than sao bradb
[02:23] <carlos> kiko, ;-)
[02:23] <jamesh> carlos: you could change your name or nick
[02:23] <SteveA_> so, are we done with brazil issues?
[02:23] <stub> I ordered some good weather and will be pissed if it doesn't get delivered on time
[02:24] <kiko> apparently it's looking good
[02:24] <carlos> SteveA_, what happens with code reviews / development ?
[02:24] <carlos> I think there is a week when most of the reviewers will be together there
[02:24] <SteveA_> carlos: reviews will still happen. development will still happen for people not in brazil.
[02:24] <kiko> it stops dead in its tracks
[02:24] <cprov> stub: lucky you, man ...
[02:24] <kiko> ;-)
[02:24] <kiko> yeah, the weather looks nice, though cold at night
[02:24] <carlos> ok
[02:24] <Kinnison> kiko: how cold at night?
[02:24] <jamesh> kiko: what does cold mean?
[02:25] <kiko> like 10C
[02:25] <kiko> a bit windy
[02:25] <Kinnison> kiko: dude, 10C would be a godsend
[02:25] <stub> Thats like *Melbourne, and the weather here *sucks*!
[02:25] <jamesh> doesn't sound too bad
[02:25] <carlos> kiko, can we use a credit card to paid there or is better if we have cash?
[02:25] <kiko> it's very dunny during the day
[02:25] <SteveA_> order order order
[02:25] <Kinnison> carlos: for food it's easier with cash
[02:25] <stub> Bwahaha
[02:26] <SteveA_>  - next rollouts
[02:26] <Kinnison> carlos: IME
[02:26] <kiko> carlos, cash will be easier I think.
[02:26] <SteveA_> stub: next rollout happen when?
[02:26] <carlos> ok, thanks
[02:26] <stub> SteveA_: Probably daily in Brazil judgind from past experience.
[02:26] <kiko> lol
[02:26] <stub> SteveA_: But nothing scheduled, because I don't know what the schedule in Brazil will be.
[02:27] <lifeless> SteveA_: we need some serious time with elmo
[02:27] <kiko> we'll work out the schedule on sunday :)
[02:27] <SteveA_> so, i'll need to make a call with elmo, or get quality irc time with him, next week
[02:28] <SteveA_> Kinnison: dogfood?
[02:28] <lifeless> yes, next week. This is to activate the new server
[02:28] <Kinnison> Right
[02:28] <Kinnison> It was updated yesterday
[02:28] <Kinnison> If anyone relies on dogfood and wants code updates, ask me, not stub
[02:28] <stub> And I have a load of monitoring stuff I need to rollout, but need some updates.
[02:29] <Kinnison> Also over the next week or so, dogfood will start ramping up with packages, builds etc, so it'll become quite an interesting place to test-bed stuff which relies on packages
[02:29] <Kinnison> I hope we'll have a small chat about dogfood in Brazil
[02:30] <kiko> why not add it as a topic?
[02:30] <Kinnison> kiko: I wasn't sure if it would be a topic, or just a natter over dinner
[02:30] <lifeless> Kinnison: topic
[02:30] <Kinnison> Okay, I'll do that
[02:30] <SteveA_> natter over dinner didn't happen particularly in cape town
[02:30] <Kinnison> SteveA_: that's about it for dogfood, thanks
[02:30] <lifeless> Kinnison: rule is - if you want it to happen: topic
[02:30] <SteveA_> any other business before we move onto three sentences?
[02:31] <kiko> dinner didn't happen in cape town for the most part
[02:31] <Kinnison> kiko: dinner happened, just..... late
[02:31] <lifeless> I'd like feedback/features on my pqm web status page
[02:31] <carlos> lifeless, it rocks, thank you ;-)
[02:31] <SteveA_> i keep forgetting the invocation.  be glad when it has been elmoed into the proper web
[02:31] <mpt> lifeless: Accessible from browsers other than lynx? :-)
[02:31] <carlos> lifeless, perhaps a page refresh every 3-5 minutes?
[02:31] <lifeless> I've heard a little 'cool' etc - but does it deliver what brad needed, what things would folk love to see?
[02:32] <lifeless> SteveA_: find me an elmo, I'll get it up ;0
[02:32] <jamesh> lifeless: dates would be good
[02:32] <kiko> Kinnison, I don't call that dinner
[02:32] <bradb> lifeless: it's definitely a step in the right direction.
[02:32] <kiko> yeah, dates definitely are needed 
[02:32] <carlos> kiko, early breakfast?
[02:32] <carlos> ;-)
[02:32] <stub> $ cat ~/bin/pqmq
[02:32] <stub> #!/bin/sh
[02:32] <stub> exec ssh chinstrap lynx --dump http://localhost:8000/
[02:33] <kiko> oh stub you are so leet 
[02:33] <Kinnison> https://chinstrap.ubuntu.com/~dsilvers/pqm.cgi
[02:33] <kiko> and that usually foobs
[02:33] <kiko> ev1l
[02:33] <kiko> lol
[02:33] <SteveA_> Kinnison: cool, link it from the wiki
[02:34] <bradb> lifeless: how can pqm be modified to deal with stale lockfiles?
[02:34] <kiko> Kinnison, you da man
[02:34] <stub> Kinnison wins
[02:34] <lifeless> bradb: ?
[02:34] <kiko> bradb, isn't the problem the lp testsuite?
[02:34] <bradb> kiko: both, i think
[02:34] <stub> pqm topic at brazil
[02:34] <Kinnison> dsilvers@chinstrap ~/public_html $ cat pqm.cgi
[02:34] <Kinnison> #!/bin/sh
[02:34] <spiv> bradb: tests need to be more robust.
[02:34] <Kinnison> echo "Content-Type: text/html"
[02:34] <Kinnison> echo
[02:34] <Kinnison> curl http://localhost:8000/
[02:34] <Kinnison> mmm evil :-)
[02:34] <SteveA_> okay
[02:34] <SteveA_> all done?
[02:34] <lifeless> bradb: pqm has a problem with lock files about once wevey 6 months
[02:34] <bradb> i think pqm should be able to run these things in such a way that it can be totally reset from the outside
[02:34] <lifeless> bradb: but lets talk later
[02:35] <Kinnison> SteveA_: I'd rather wait until it's properly elmoed
[02:35] <cprov> Kinnison: indeed, but works ;)
[02:35] <Kinnison> SteveA_: In particular it ideally should be http://pqm.ubuntu.com/ or something
[02:35] <lifeless> Kinnison: thats why I want elmo, have been trying to get him all week
[02:35] <SteveA_> Kinnison: voltaire, best, good, not best of friends
[02:35] <lifeless> Kinnison: but can't get boo out of debconf, its like a black hole.
[02:35] <kiko> Kinnison, lifeless: solutions that work now are what we want
[02:36] <lifeless> kiko: thus my lynx invocation I documented.
[02:36] <lifeless> kiko: which works just fine ;0
[02:36] <kiko> Kinnison's is more leet :-P
[02:36] <SteveA_> okay
[02:36] <SteveA_> time for three sentences
[02:36] <stub> DONE: Monitoring and DBA stuff
[02:36] <stub> TODO: Survive Brazil
[02:36] <stub> BLOCKED: Elmo time
[02:36] <mpt> DONE: Some decruftification, many bug reports, LaunchpadHierarchyNavigation spec
[02:36] <mpt> TODO: Nelson to Sao Paulo in five easy steps, specs, fixing headings
[02:36] <mpt> BLOCKED: Offline until Monday
 TODO: more import testing, sourcerer on gina every day
 DONE: import testing from z-g, dyson test runs on staging
 BLOCKERS: none
[02:36] <debonzi> DONE: Gina; Little launchpad cleanup; some work on distro/distrorelease bits on launchpad
[02:36] <debonzi> TODO: Get gina merged on rocketfuel; Brazil sprint.
[02:36] <debonzi> BLOCKED: Gina Review.
[02:36] <kiko> DONE: LP report (yay), linkification, malone cleanups, reviews, sprint 
[02:36] <kiko> prep, some other random crap.
[02:36] <kiko> TODO: more malone cleanups, sprint org, spec reviews (yay), LP report
[02:36] <kiko> BLOCKED: not really
[02:36] <bradb> DONE: Landed some usability fixes (autofocus issues, de-underlining action portlet links. Usability testing with jbailey; braindump and discussion on launchpad@. Small FBN fixes. 20% through lp menu integration. Code review of one of kiko's branches. pqm pain.
[02:36] <SteveA_> DONE: DPoT links, reviews, menus improvements
[02:36] <SteveA_> TODO: go to brazil, reviews, navigation class
[02:36] <SteveA_> BLOCKED: no
[02:36] <lifeless> DONE: pqm feedback, 50% of new tree format work.
[02:36] <carlos> DONE: Karma, POImport fixes, datamigration / poexport data fixes, languagepacks
[02:36] <jamesh> DONE: code reviews, timezone preferences and calendar cleanups, some LaunchpadIntegration work, other bug fixes.
[02:36] <carlos> TODO: Karma, languagepacks, Rosetta cleanups, GNOME imports
[02:36] <carlos> BLOCKED: l10n-status.gnome.org update
[02:36] <jamesh> TODO: code reviews, Brazil, more calendar cleanups
[02:36] <jamesh> BLOCKED: none
[02:36] <bradb> TODO: Discuss the "advanced search screen" with mpt. Land the other 6 active branches I have going (probably a couple today) before thinking of starting something else.
[02:36] <BjornT> DONE: various small fixes. reviews. try to fix a bug in BBA implementation. some work on the email interface.
[02:36] <bradb> BLOCKED: mpt said "advanced search screen" when talking of Malone lp menu integration! Discussion required.
[02:36] <jblack> DONE: metric shitloads of imports
[02:36] <BjornT> TODO: more general malone work. unbreak email interface.fix email threading.
[02:36] <BjornT> BLOCKED: spec approval (BBA) from kiko
[02:37] <lifeless> TODO apply-changeset, tuninging, recording of changed revisions
[02:37] <jblack> TODO: metric shitloads of imports, travel
[02:37] <cprov> DONE: GPG/CoC merge in RF, bug trancking and minor issues for production
[02:37] <cprov> TODO: setup buildd-master stuff on DF
[02:37] <cprov> BLOCKED: slow access to DF most part of the day and DF infrastructure bits
[02:37] <lifeless> BLOCKED: nothing particular
[02:37] <jblack> BLOCKED: None
[02:37] <spiv> DONE: holidays, mail catchup, sent sqlobject patches upstream, reviews.
[02:37] <spiv> TODO: reviewing, sqlobject distinct/orderby issues, enumcol subsets.
[02:37] <spiv> BLOCKED: no.
[02:37] <Kinnison> DONE: Dogfood preparation, molodezhnaya.buildd installation.
[02:37] <Kinnison> TODO: Get Dogfood actually using the buildd, get gina going, get uploader deployed to dogfood, get production's gina and publisher going
[02:37] <Kinnison> BLOCKED: Gina in production needs a couple more branches reviewing and merged
[02:37] <salgado> DONE: BasicVoting (got a first round up for review), code review, lots of fixes
[02:37] <salgado> TODO: Apply review requests into first round of BasicVoting and start the second round, get sqlobject's tests running on "make check_merge", code review, random fixes
[02:37] <salgado> BLOCKED: None
[02:37] <morgs> DONE: RDF bugfixing, Registry Bugfixing, DoapSchemaNG
[02:37] <morgs> TODO: Bugfixing, DoapSchemaNG
[02:37] <morgs> BLOCKED: None
[02:38] <SteveA_> okay
[02:38] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  removed some imports from the set that get warned about by the import fascist. (patch-2101: steve.alexander@canonical.com)
[02:38] <SteveA_> let's go through the blocked items
 BLOCKED: Gina Review.
[02:38] <SteveA_> who needs to do that?
[02:38] <kiko> I don't want to anymore
[02:38] <lifeless> btw - pqm dates - 1121342583 - cant you read unix time ;)
[02:38] <debonzi> SteveA_, don't know
[02:38] <SteveA_> can any reviewer do it?
[02:39] <SteveA_> BjornT or salgado: can you do it?
 BLOCKED: l10n-status.gnome.org update
[02:39] <SteveA_> who can unblock you, carlos ?
[02:39] <carlos> SteveA_, myself
[02:39] <SteveA_> then, you're not blocked
[02:39] <carlos> SteveA_, but it's outside work
[02:40] <salgado> SteveA_, I don't think I can do it today. :(
[02:40] <BjornT> SteveA_: i won't have time today, but i could do it tomorrow in the morning
 BLOCKED: mpt said "advanced search screen" when talking of Malone lp menu integration! Discussion required.
[02:40] <carlos> ok
[02:40] <SteveA_> BjornT: okay, please do.  thanks
[02:40] <SteveA_> mpt: can you talk with brad after this meeting?
[02:40] <debonzi> Thanks SteveA_, BjornT 
 BLOCKED: spec approval (BBA) from kiko
[02:40] <SteveA_> kiko, BjornT: ?
[02:40] <mpt> SteveA_: sure
[02:40] <kiko> yeah
[02:40] <kiko> will do today
[02:40] <kiko> it's been queued, not forgotten
 BLOCKED: slow access to DF most part of the day and DF infrastructure bits
[02:41] <SteveA_> Kinnison: can you help with this?
[02:41] <kiko> can't really solve the first 50% :-(
[02:41] <Kinnison> SteveA_: I imagine I can. I'll be talking with cprov for our daily soyuz meeting after this meeting
[02:41] <SteveA_> ok
 BLOCKED: Gina in production needs a couple more branches reviewing and merged
[02:41] <Kinnison> SteveA_: the first half is due to .br's netlink being shit
[02:41] <Kinnison> SteveA_: those are debonzi's branches
[02:42] <SteveA_> okay, so sorted
[02:42] <SteveA_> anyone have blocked items that haven't been dealt with somehow?
[02:43] <SteveA_> one more thing then,
[02:43] <SteveA_> when you run the tests, for example with: python test.py canonical
[02:43] <cprov> SteveA_: dsilvers has helped me as he can, we are in touch, very close to be precise .
[02:43] <SteveA_> look at the guff at the end, after the "OK"
[02:43] <SteveA_> see if any of it belongs to you
[02:43] <SteveA_> if so, fix it.
[02:43] <SteveA_> i fixed the last hct one today, after talking with scott
[02:44] <SteveA_> carlos has the rosetta ones on his todo list
[02:44] <SteveA_> salgado: still a few from you
[02:44] <SteveA_> morgs has the registry ones on his todo list
[02:44] <salgado> SteveA_, really? I'll fix them today
[02:44] <SteveA_> cool
[02:44] <SteveA_> oh, next meeting?
[02:44] <carlos> SteveA_, I forgot one thing. I'm having problems with twistd2.0 and launchpad tests, I know it's not a priority but if someone that knows more about twisted than me could help there...
[02:44] <Kinnison> debonzi: Will you take on the soyuz ones while waiting for the gina stuff to get merged?
[02:44] <SteveA_> same time next week, provisionally.  but we'll arrange in brazil.
[02:45] <SteveA_> countdown of woe
[02:45] <SteveA_> 5
[02:45] <debonzi> Kinnison, yep
[02:45] <SteveA_> 4
[02:45] <SteveA_> 3
[02:45] <SteveA_> 2
[02:45] <SteveA_> 1
[02:45] <Kinnison> debonzi: thanks
[02:45] <SteveA_> MEETING ENDS
[02:45] <Kinnison> woohoo
[02:45] <spiv> carlos: Sure, I can spend a moment on that now before I crash if you like.
[02:45] <debonzi> Kinnison, any special request?
[02:45] <carlos> spiv, that would be perfect, thanks
[02:46] <Kinnison> debonzi: just run a full test suite and then check for any soyuz-related fascism warnings etc
[02:46] <kiko> stub, let me ask you one thing
[02:46] <kiko> what's this cronspam we're getting now?
[02:46] <Kinnison> debonzi: then if you've done all those, go through the soyuz UI and check there's nothing which is going to explode horribly
[02:46] <debonzi> Kinnison, right.. will do
[02:46] <mpt> bradb: We already have an advanced search page
[02:46] <Kinnison> debonzi: If you need me to cherrypick fixes into dogfood for you to test, let me know
[02:46] <mpt> bradb: It just happens to have a batch of results in the middle of it.
[02:47] <Kinnison> debonzi: I don't mind being telephoned to do stuff either
[02:47] <stub> kiko: You need to be more specific - there is a lot of cronspam.
[02:47] <debonzi> Kinnison, cool.. thanks
[02:47] <Kinnison> debonzi: but as a word of warning, I will be going out tonight
[02:47] <carlos> spiv, the main problem is that from time to time, twistd is not ready before we start using it (seems like the log trick is not working correctly)
[02:47] <bradb> mpt: are we committing to having a page with just the advanced search widgets on it + results show on a separate page?
[02:47] <carlos> and when it's ready, I get internal server errors
[02:47] <Kinnison> debonzi: so if you don't catch me in the next 5h or so I'll be gone
[02:47] <mpt> bradb: No.
[02:48] <carlos> spiv, if you give me some instructions about how could I debug it...
[02:48] <debonzi> Kinnison, right.. 
[02:48] <kiko> stub, 
[02:48] <kiko> python: can't open file 'cronscripts/process-mail.py': [Errno 2]  No such file or
[02:48] <kiko> +directory
[02:48] <carlos> (I'm talking about librarian using twistd)
[02:48] <mpt> bradb: The current results page can stay just as it is. (It will eventually need redesigning, but that's a separate issue.)
[02:48] <stub> kiko: That was a dud crontab entry we didn't notice for several hours because the mailing lists were blocked.
[02:48] <kiko> mpt, seconded
[02:49] <kiko> stub, I still got some today, but I guess that's just mailman catching up
[02:49] <spiv> carlos: Hmm.
[02:49] <bradb> mpt: sure, but do you mean that we're just going to plop the screen you'd get if you clicked the "Advanced" button under "Show Reports" now instead?
[02:50] <mpt> bradb: All search results should be under the "Show Reports" tab anyway.
[02:50] <bradb> mpt: right, but i'm asking you about the advanced search page, not the results page.
[02:51] <bradb> more specifically, about the page you currently get when you click "Advanced"
[02:51] <bradb> (which, tbh, looks like arse)
[02:51] <spiv> carlos: So, the current ready magic is slightly buggy.
[02:52] <mpt> bradb: You were asking me if clicking "Advanced" would take you to Show Reports. My answer: You're already *in* the Show Reports section, and you stay in that section.
[02:53] <bradb> mpt: ok, let's walk through this: 1. https://launchpad.ubuntu.com/products/malone/+bugs, as an example starting point...
[02:53] <mpt> bradb: That page is in the "Malone Bugs" tab.
[02:53] <carlos> spiv, yes, I think it's because we get the log output when the process is launched
[02:53] <bradb> mpt: right, so, i immediately realize that i want to do an Advanced Search.
[02:53] <carlos> spiv, and it depends on how fast is it to start listening requests it fails or not
[02:54] <mpt> bradb: MaloneFrontPages will give you an "Advanced Search" link.
[02:54] <bradb> mpt: I have the following options. "Malone Bugs", "Report a Bug", "Show Reports"
[02:54] <carlos> I suppose other people will have the same problem with twistd 1.x if the machine is not fast enough
[02:54] <bradb> i click on "Show Reports", where does it take me?
[02:54] <salgado> stub, can I nuke that person/+review page?
[02:55] <mpt> bradb: To the advanced search page also.
[02:55] <spiv> carlos: actually, I don't think it's possible with twistd 1.x and the old test.
[02:55] <spiv> But more by accident than good design :)
[02:55] <mpt> bradb: That's a duplicate link, which I understand is awkward, but IMO it's better than having jumping tabs.
[02:55] <bradb> mpt: right, so, is clicking on "Show Reports" going to take you to precisely the page you'd see right now if you clicked on the "Advanced" button on the link i pasted?
[02:56] <bradb> (with the Advanced/Simple button removed, of course)
[02:56] <carlos> spiv, ok
[02:56] <mpt> bradb: yes.
[02:57] <bradb> mpt: if you click the "Advanced" button currently, what do you see change in your browser when the page comes back?
[02:57] <stub> salgado: I don't know.
[02:58] <mpt> bradb: There's some extra form controls down the bottom, iirc
[02:58] <SteveA_> cprov: hi
[02:58] <salgado> stub, everything that we test on that page is tested on other pages
[02:58] <bradb> mpt: doesn't it require scrolling to see those?
[02:58] <SteveA_> cprov: i see in comments in the builddmaster, you have plans to make it use zcml-for-scripts
[02:58] <spiv> carlos: So, the simplest solution is probably like this:
[02:59] <mpt> bradb: Yes it does, which is bad, which is why the page needs redesigning, but as I said, that is a separate issue.
[02:59] <bradb> ok
[02:59] <SteveA_> morgs, cprov, debonzi:  ProductSeriesSet, ProductMilestoneSet, SourcePackageSet are imported into browser/traversers.py from database code
[02:59] <mpt> bradb: The Advanced Search page I'm suggestnig here would be that page, but minus the batched results, so it wouldn't need scrolling.
[02:59] <spiv> class ReadyService: def startService(self): log.msg("ready!"); ReadyService().setServiceParent(librarianService)
[02:59] <SteveA_> would be really great to get rid of these
[03:00] <spiv> carlos: Making sure that is the last service to be added.
[03:00] <mpt> bradb: And remember, that would be an *additional* page, it wouldn't alter any existing page in Launchpad.
[03:00] <bradb> mpt: right, that's what i'd like to see too (and a lot more useful widgets)
[03:00] <stub> salgado: If it is useless then nuke it I guess. I don't know what is on there, or if there are other tools admins can use to do stuff (eg. change peoples passwords, merge accounts, whatever).
[03:01] <carlos> hmm
[03:01] <carlos> spiv, but how could we be sure that it will be last service added when using, for instance buildd?
[03:01] <spiv> carlos: So long as it's the last call to setServiceParent in the tac file, sure.
[03:02] <carlos> or in the future, if someone adds a new service that needs librarian?
[03:02] <carlos> spiv, when you talk about services, you mean inside the script? or different .tac files?
[03:02] <salgado> stub, I thought you have created it just to test the new password widget. I'm going to leave it there, then. 
[03:03] <spiv> A more complex solution would be a service that does reactor.addSystemEventTrigger('after', 'startup', log.msg, 'ready!') in its startService.
[03:03] <spiv> That ought to avoid any issues with the order the service is added.
[03:03] <mpt> bradb: Is that all clear as mud?
[03:04] <mpt> bradb: I'm fully aware that this categorization of pages may be completely crack, but it's what I came up with in Montreal, and I've been trying to think of a better categorization since then and failed.
[03:05] <carlos> spiv, would you add it? I'm not feeling too confident I will do it correctly as twistd is completely new to me...
[03:05] <bradb> mpt: sure, it's a step in the right direction, in any case :)
[03:05] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Update dogfood config to be able to start trebuchet etc (patch-2102: daniel.silverstone@canonical.com)
[03:05] <carlos> also, that will solve the timeout problem, now, I need to solve the Internal server error problem
[03:05] <carlos> any hint to get a trace?
[03:05] <bradb> mpt: we can already predict what sabdfl will say when he clicks on "Show Reports" though :)
[03:05] <spiv> carlos: Mail me about it, I'm too sleepy to do that at the moment.
[03:06] <bradb> back in a few mins
[03:07] <carlos> spiv, ok, thank you !
[03:07] <spiv> carlos: Where's the internal server error you're referring to?
[03:07] <spiv> In the librarian?
[03:07] <carlos> yesh
[03:07] <carlos> yes
[03:08] <spiv> That's easy ;)
[03:08] <spiv> Comment out this line in the librarian.tac:
[03:08] <spiv> site.displayTracebacks = False
[03:08] <carlos> :-)
[03:09] <carlos> thank you, will try to debug it and will send you an email if I'm not able to fix it.
[03:09] <spiv> Cool.
[03:10] <spiv> Also, regardless of that setting, it will log the tracebacks.
[03:10] <carlos> but the log is removed when the test ends, right?
[03:10] <cprov> SteveA_: yes, I have plans to store some config bits for builddmaster stuff in zcml, but not exactly now (before sprint), we need to discuss and spec it out 
[03:10] <carlos> from /var/tmp/fatsam.test/
[03:10] <stub> salgado: oh - ok. Don't keep it around if it is no longer useful - your call. 
[03:10] <spiv> Yeah.  You might want to comment out that bit of the test harness ;0
[03:11] <SteveA_> cprov: i'm talking about using IFooSet rather that FooSet
[03:11] <spiv> Ideally the tearDown wouldn't remove that stuff if the test failed, because it can be useful for diagnosis.
[03:11] <carlos> ok
[03:11] <spiv> Probably what should happen is that the directory should be removed in setUp rather than tearDown.
[03:11] <cprov> SteveA_: sure, we also need it for getUtility()
[03:11] <spiv> Which would also make the tests more robust.
[03:12] <mpt> bradb: All bug report pages and task pages are in the "Show Reports" section too, btw
[03:15] <lifeless> https://wiki.launchpad.canonical.com/PqmRobustness
[03:15] <lifeless> feedback solicted
[03:18] <carlos> lifeless, will you be around tomorrow? 
[03:18] <carlos> I have a patch waiting for pqm that I need to be cherrypicked into production
[03:18] <kiko> SteveA_, duderino?
[03:19] <SteveA_> kiko: yep
[03:19] <SteveA_> i'm going to disappear for quite a while soon, to pack, do last minute stuff
[03:19] <kiko> well
[03:19] <kiko> I'm concerned about
[03:19] <kiko> > +    def _linkify_substitution(match):
[03:19] <kiko> ...
[03:19] <kiko> > +            url = '/malone/bugs/%s' % match.group('bugnum')
[03:20] <kiko> hadn't we agreed to use an IBugSet utility?
[03:20] <kiko> building the URL manually here is asking for pain
[03:20] <SteveA_> can't yet
[03:20] <kiko> why not?
[03:20] <kiko> my code used it (AFAICT)
[03:20] <SteveA_> because it makes the code really messy when you have private bugs
[03:20] <SteveA_> that needs to be fixed first
[03:20] <SteveA_> also, we need to decide what to do about bugs that don't exist
[03:21] <SteveA_> do they get linked?  where to?
[03:21] <kiko> SteveA_, just don't linkify them, as bugzilla does.
[03:21] <kiko> it's a cheap solution
[03:21] <SteveA_> the spec needs to say these things
[03:21] <SteveA_> when i can get a canonical_url for a private bug, i'll change the code
[03:21] <debonzi> SteveA_, how do I use getUtility for Interfaces were the class has an __init__? like it is on ISourcePackageSet?
[03:21] <SteveA_> does the object have state?
[03:22] <SteveA_> if so, it should not be a xxxSet
[03:22] <kiko> SteveA_, what's the reason canonical_url doesn't work?
[03:22] <kiko> I'd much rather we didn't linkify private bugs
[03:22] <SteveA_> kiko: the id attribute of the bug is private
[03:22] <SteveA_> um, forbidden
[03:22] <SteveA_> no reason for it to be so
[03:22] <SteveA_> debonzi: when i last looked at SourcePackageSet, it was bad code
[03:23] <SteveA_> it was a pun, between the singleton SourcePackageSet, and a SourcePackageSubset
[03:23] <SteveA_> it should be split into two classes, two interfaces
[03:23] <kiko> SteveA_, can't you just try/except and XXX it?
[03:23] <kiko> you just lost bug titles in the links...
[03:24] <SteveA_> i have no idea what you're talking about
[03:24] <SteveA_> can you file a bug please?
[03:24] <SteveA_> say exactly what behaviour you want
[03:24] <SteveA_> in the bug
[03:24] <kiko> you've already filed a bug on canonical_url
[03:24] <kiko> I can try fixing it :-P
[03:24] <SteveA_> it sounds like you want different behaviour
[03:24] <debonzi> SteveA_, yep.. we talked about it.. but even them It seems that Subset will have an __init__ .. so it is not possible to use with getUtility right?
[03:25] <SteveA_> kiko: if the code works well enough as it stands, then let's fix it when the canonical_url bug is fixed.
[03:25] <kiko> SteveA_, no, I just don't want less functionality than I provided you with initially :-P
[03:25] <SteveA_> kiko: if you want different functionality, then file a bug
[03:25] <kiko> SteveA_, it hardcodes the malone URL, and it doesn't give bug titles, which the code I gave you /did/!
[03:25] <SteveA_> kiko: writing code is not the way to get functionality.  providing test cases is
[03:25] <SteveA_> my code does give bug titles
[03:25] <SteveA_> i think you need to wait for another merge
[03:25] <kiko> yeah
[03:25] <SteveA_> from pqm
[03:25] <kiko> I'm waiting
[03:26] <SteveA_> so, i'm going to get on with other stuff
[03:26] <kiko> I'll see what I can do about that hardcoded URL. evil SteveA_.
[03:27] <SteveA_> kiko: please don't change it until the canonical_url bug is fixed
[03:27] <SteveA_> i left it that way for a reason, and there's a comment in there
[03:27] <kiko> well
[03:27] <SteveA_> i don't want to see complex code to work around a problem that will be fixed soon
[03:27] <kiko> how does the canonical_url bug manifest itself?
[03:27] <SteveA_> when it makes no difference now
[03:27] <kiko> is an exception raised when you call it?
[03:27] <SteveA_> kiko: you have better things to do
[03:28] <kiko> perhaps, but I am interested in the rationale, as always
[03:28] <SteveA_> the rationale is, don't add complex code (that wouldn't be tested properly) to work around a separate issue that will be fixed soon anyway
[03:29] <SteveA_> now, if you want private bugs to be unlinked
[03:29] <SteveA_> and non-existent bugs to be unlined
[03:29] <kiko> that would be a perfectly fine workaround for now
[03:29] <SteveA_> unlinked ,
[03:29] <SteveA_> then that's another issue entirely
[03:29] <kiko> I'm just asking if that wouldn't be a non-complex way of dealing with the issue..
[03:29] <SteveA_> if that is the desired behaviour, then the tests and code can be changed to accommodate that
[03:30] <kiko> I think if you can see a private bug, then it should be linked and titled. 
[03:30] <kiko> if you can't see it, then not linking is an easy way out -- as is not linking a bug which doesn't exist.
[03:31] <kiko>   CHECKSUM FILE(S) DISAGREE WITH
[03:31] <kiko>   DIRECTORY LISTING ABOUT WHAT
[03:31] <kiko>   FILES SHOULD BE PRESENT IN
[03:31] <kiko>   REVISION DIR OF ARCHIVE
[03:31] <kiko> heh
[03:31] <kiko> go baz go
[03:31] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Agglomeration of three one-line fixes to packaging of buildd (patch-2103: daniel.silverstone@canonical.com)
[03:33] <SteveA_> kiko: file me a bug and i'll get to it later today
[03:34] <kiko> ok ok
[03:50] <bradb> SteveA_: any page title love?
[03:56] <lifeless> night all
[03:57] <lifeless> if anyone wants to give me feedback on that pqm brain dump that would rock
[04:10] <kiko> hey carlos?
[04:13] <kiko> uhm BjornT, bradb?
[04:14] <kiko> I replied via email to bug 1452, but I trimmed the CC: list and replied only to the bug
[04:14] <kiko> the comment was added but no notification was sent
[04:14] <kiko> is this correct?
[04:14] <BjornT> kiko: it's a bug. i'll fix that one today
[04:15] <kiko> is it reported? did you know about it?
[04:18] <BjornT> kiko: it's reported indirectly. the problem is that canonical_url can't be used in scripts (which is reported).
[04:19] <SteveA_> BjornT: i told you how to fix that
[04:21] <BjornT> SteveA_: yes i know. and i'll fix it today, together with another bug as well.
[04:21] <SteveA_> cool
[04:21] <SteveA_> another bug in zcml for scripts?
[04:21] <SteveA_> another bug in canonical urls?
[04:24] <kiko> bug 1441 I suspect
[04:24] <BjornT> SteveA_: no. it's when an error occurs, an error mail get sent. but the link to the message in librarian doesn't work.
[04:25] <BjornT> kiko: yes
[04:25] <kiko> you da man
[04:25] <kiko> fix and cherry
[04:26] <SteveA_> Kinnison: https://chinstrap.ubuntu.com/~dsilvers/pqm.cgi should say the charset is utf8
[04:30] <Kinnison> SteveA_: done
[04:31] <salgado> SteveA_, the problem with PersonView.assignedBugsToShow() is that it makes a query and use the result of that query in a boolean context. that then calls the result's __len__ method and that method issues a self.clone(orderBy='')
[04:34] <salgado> how can I fix it?
[04:34] <Kinnison> :q
[04:34] <Kinnison> feh
[04:35] <Kinnison> irssi != wim
[04:35] <Kinnison> erm vim
[04:35] <SteveA_> vim venders
[04:35] <SteveA_> salgado: where'sthe code?
[04:35] <SteveA_> in the PersonView class i guess
[04:35] <salgado> launchpad/browser/person.py:166
[04:35] <salgado> 176
[04:36] <salgado> if I do a count() on the results of both queries inside the bool() call it will not raise the warning
[04:36] <SteveA_> okay
[04:37] <salgado> but I don't want to do that. I think it's clearer the way it is
[04:38] <SteveA_> well, hang on
[04:38] <SteveA_> this doesn't make sense
[04:38] <SteveA_> by saying         return bool(self.mostImportantBugTasks() or self.mostRecentBugTasks())
[04:39] <SteveA_> you are calling        results = bts.assignedBugTasks(
[04:39] <SteveA_>                         self.context, orderBy=orderBy, user=self.user)
[04:39] <SteveA_> 
[04:39] <SteveA_> twice
[04:39] <SteveA_> all you want to know is, are there any assigned bugtasks at all
[04:39] <SteveA_> so, there is a much simpler query
[04:39] <SteveA_> better still, 
[04:40] <salgado> indeed. who wrote this crap code? (/me hides)
[04:40] <SteveA_> get the mostRecentBugTasks and mostImportantBugTasks earlier in the processing of the page template
[04:40] <SteveA_> with a tal:define perhaps
[04:40] <SteveA_> the tal:define would call something in the view clas
[04:40] <SteveA_> that gets and stores the results of:
[04:40] <SteveA_>  - most recent bugtasks
[04:40] <SteveA_>  - most important bug tasks
[04:41] <SteveA_>  - bool: are there any bugtasks
[04:41] <SteveA_> it would be called set_up_bug_tasks_to_show, or something like that
[04:41] <SteveA_> there's some ideas on how to structure this better
[04:41] <SteveA_> but, you know the code better then i do
[04:42] <salgado> I can see what you're suggesting. it looks easy to do and better than what we have now
[04:43] <salgado> but anyway, why the warning is raised in that case?
[04:43] <salgado> if I call __len__() explicitly it won't be raised
[04:43] <SteveA_> i don't have time to look into it in detail now
[04:44] <SteveA_> launchpad seems to have stalled
[04:46] <SteveA_> seeing as i can't comment on the bug
[04:47] <SteveA_> bradb, kiko: note that 'distrorelease' is a noun.  it is a thing.  'reportedin' is not a thing.  it is a predicate or relationship, but not a noun.
[04:48] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Many fixes and tests for the poimport script r=salgado (patch-2104: carlos.perello@canonical.com)
[04:48] <kiko> true.
[04:48] <kiko> who say mpool last?
[04:49] <bradb> SteveA_: just curious: if you approached a random member of MOTU (who had some basic knowledge of ifaces) and asked "what's an IBugTask.workplace?", how likely do you think their answer will line up with what the actual meaning of that attribute is? what about if you asked "what's an IBugTask.reportedin?"
[04:49] <kiko> he didn't get off the plane he said he was going to and the people collecting him are calling me
[04:49] <kiko> bradb, first, you'd need to explain to them what tasks were.
[04:49] <kiko> :)
[04:49] <SteveA_> bradb: they'd say "brad, tell me what a workplace is" or "brad, tell me what a target is", or "brad, your grammar is atrocious" (for the last one)
[04:50] <kiko> SteveA_, you're tearing 'em apart today
[04:50] <SteveA_> it's fine to use a predicate
[04:50] <SteveA_> so, "wherereported" would be okay
[04:50] <SteveA_> that's more of a noun
[04:51] <SteveA_>  if task.wherereported == myproduct:
[04:51] <SteveA_>  print task.wherereported
[04:51] <kiko> or place reported, but that is using "place" instead of target
[04:51] <kiko> if task.target == myproduct:
[04:51] <SteveA_> target is ambiguous
[04:51] <kiko> if task.workplace == myproduct:
[04:51] <SteveA_> makes me think of milestones
[04:51] <kiko> really?
[04:51] <kiko> ah, good point
[04:51] <kiko> fair enough
[04:56] <morgs> Is Launchpad still pondering the meaning of life?
[04:56] <kiko> the topic is full, foo
[04:56] <kiko> the answer is "maybe"
[04:56] <Kinnison> kiko: full?!
[04:57] <Kinnison> stub: you there?
[04:58] <Kinnison> stub: Any chance of getting things fixed on dogfood so that the launchpad user can IDENT as any user to launchpad_dogfood?
[04:58] <Kinnison> stub: We're kinda blocked on that right now
[04:58] <bradb> kiko: would you be willing to do a drive-by review of my absolute_url -> canonical_url cleanup branch?
[04:58] <stub> Kinnison: ok
[04:59] <kiko> bradb, why not?
[04:59] <Kinnison> stub: thanks dude
[04:59] <bradb> wicked. i'll ping you when finished bazzing. thanks.
[04:59] <Kinnison> stub: I'll buy you lunch one of the days in Brazil
[04:59] <kiko> stub, you arrive here on the 15th, right? mpool seems to have gotten the dates wrong.
[05:00] <stub> I arrive on the 15th at 17:17
[05:01] <kiko> okay, thanks.
[05:02] <Kinnison> stub: do you need me to stop dogfood for the perms change or can it be done without a restart?
[05:05] <bradb> SteveA_: btw, i just asked a (semi-)random user what they guessed .workplace and .reportedin to mean. i can give you their feedback, if you think it would help choose a good name for this apparently flame-war-inducing attribute. :P
[05:05] <kiko> bradb, use workplace, seriously, it's the right word
[05:05] <stub> Kinnison: That should be fixed, at least for all the accounts defined in security.cfg
[05:05] <bradb> kiko: heh
[05:07] <bradb> er, maybe you were seriously being serious, i dunno
[05:08] <kiko> I was!
[05:08] <Kinnison> stub: You're a star, thanks dude
[05:08] <bradb> kiko: like pillars of launchpad serious?
[05:08] <bradb> :P
[05:08] <kiko> hate!
[05:09] <bradb> right, if you guys are thoroughly convinced that workplace is the right word, i'll totally change it. sabdfl will speak up if he doesn't like it, to be sure.
[05:13] <kiko> I see your phear
[05:17] <bradb> kiko: you've got patchmail!
[05:18] <bradb> (er, not for the attribute thing yet though :)
[05:18] <bradb> that is provably impossible to do /that/ quickly with baz in the way
[05:18] <salgado> SteveA_, ping
[05:35] <bradb> is it me, or is switching to a branch you're already on an absolute disaster?
[05:39] <bradb> one might ask "why would you switch to a branch you're already on?" well, because i ran out of disk space in the middle of branch switching, of course. tree-version reported that i was on the branch i wanted to switch to, but i thought i'd clear out 2 gigs of lovely baz implementation details and run the switch command again, just to be doubly sure.
[05:40] <salgado> bradb, when a switch fails I usually do: "baz tree-version <the-version-you-were-switching-from> ; baz undo"
[05:41] <bradb> interesting
[05:42] <bradb> first i have to unbreak the duplicate ids and such
[06:02] <SteveA_> salgado-lunch: 
[06:37] <salgado> SteveA_, so, should I use a count() to get rid of the warning or can I leave a big XXX there so we'll look and find the problem later?
[07:01] <jblack> Launchpad has looked down to me for a couple hours. Is it coming back any time soon?" 
[07:24] <kiko> not afaik
[07:30] <bradb> kiko: any chance i could nag you to look at that patch this afternoon? it consists of basically 1. removing two classes, 2. changing calls to absolute_url to fmt:url.
[07:34] <salgado> https://chinstrap.ubuntu.com/~dsilvers/paste/filey4GD0l.html
[07:34] <Kinnison> ciao dudes
[07:34] <salgado> there's quite a few of these errors on production's launchpad.log
[07:35] <kiko> bradb, you're removing two templates, too. I already did it.
[07:36] <kiko> carlos?
[07:36] <kiko> can somebody call carlos?
[07:36] <kiko> this is the suck
[07:36] <bradb> kiko: i am?
[07:36] <kiko> yeah.
[07:36] <bradb> where?
[07:36] <kiko> look in your inbox
[07:36] <kiko> crazy man
[07:37] <bradb> ah yes, i guess i chopped those off in this branch too
[07:38] <bradb> getting it down to 5 active branches will make my life that much easier
[07:38] <kiko> SteveA_?
[07:38] <kiko> this is so sucky
[07:38] <kiko> no launchpad
[07:38] <kiko> and no admin
[07:41] <bradb> and it won't get any better for 1.0, AFAIK :/
[07:41] <kiko> it will have to
[07:42] <bradb> i agree/hope
[07:43] <kiko> carlos will be around in 15"
[07:43] <kiko> err 15'
[07:44] <kiko> we need to find somebody to productize a patch, though, which is highly unfortunate.
[07:46] <stub> kiko: Last hits to launchpad were here: https://chinstrap.ubuntu.com/~dsilvers/paste/fileU85Glj.html
[07:46] <stub> Same problem as per bug report (lockups, POSubmission)
[07:46] <kiko> stub, and it's a different problem than https://chinstrap.ubuntu.com/~dsilvers/paste/filey4GD0l.html, yes?
[07:47] <stub> There are also a load of po-attach processes hung trying to call sendmail
[07:47] <stub> kiko: No idea - I gotta go in a sec
[07:47] <kiko> what's up with sendmail?
[07:47] <kiko> that's the suck
[07:47] <kiko> stub, what do we do while you're away?
[07:48] <kiko> well, we have lifeless in 7h or so
[07:48] <kiko> stub, so your workaround didn't work around the issue?
[07:49] <stub> All killed and restarted
[07:49] <kiko> I got some poattach mail again
[07:50] <stub> kiko: The workaround (break /rosetta) was switched off. But there is still a problem that needs tracking down.
[07:50] <kiko> the broken query you reported via email?
[07:50] <stub> kiko: Robert might need to 'revoke all on posubmission from write;revoke all on posubmission from launchpad' To break /rosetta again if it happens again.
[07:51] <kiko> fair enough
[07:51] <stub> kiko: Reported as a bug, critical etc.
[07:52] <stub> I gotta go - see you tomorrow or whenever (datelines confuse me)
[08:07] <carlos> I see the error
[08:07] <carlos> kiko, that should be more or less easy, it should be related to mark's changes to move from productrelease to productseries
[08:08] <carlos> kiko, you scared me! I thought production was completely broken (we talk about a production problem this mornign with stub)
[08:09] <kiko> carlos, it was completely broken for 2h
[08:09] <kiko> and it will be again very soon if we don't get traction on it
[08:10] <carlos> kiko, do you think it's related to the trace salgado pasted?
[08:14] <kiko> sorry, had an interview
[08:14] <kiko> carlos, I don't think so, though fixing that would be an absolute plus
[08:14] <kiko> I think stub's paste is more relevant
[08:14] <kiko> in particular:
[08:14] <kiko> 127.0.0.1 - Anonymous [14/Jul/2005:16:40:47 +0100]  "GET /++vh++https:launchpad.ubuntu.com:443/++/distros/ubuntu/breezy/+translations HTTP/1.1" 200 68467 "https://launchpad.ubuntu.com/rosetta" "Mozilla/5.0 (X11; U; Linux i686; pt-BR; rv:1.7.6) Gecko/20050306 Firefox/1.0.1 (Debian package 1.0.1-2)"
[08:15] <carlos> kiko, at what time was that ?
[08:15] <salgado> [14/Jul/2005:16:40:47 +0100] 
[08:15] <carlos> kiko, I was talking with stub about a big performance problem
[08:15] <carlos> this morning
[08:16] <kiko> carlos, those were the last links that anybody hit on launchpad
[08:16] <carlos> and he told me that it was an index problem and told me that I don't need to care about it
[08:16] <kiko> maybe
[08:16] <kiko> he said a critical bug was filed on it
[08:16] <kiko> do you have a bug #?
[08:16] <salgado> 1444
[08:17] <carlos> https://launchpad.ubuntu.com/malone/bugs/1444 ?
[08:17] <carlos> that's exactly the bug we talked about
[08:17] <salgado> 127.0.0.1 - Anonymous [14/Jul/2005:19:16:58 +0100]  "GET /++vh++https:launchpad.ubuntu.com:443/++/people/lifeless HTTP/1.1" 200 5417 "" "Googlebot/2.1 (+http://www.googlebot.com/bot.html)"
[08:17] <salgado> googlebot is back
[08:17] <kiko> carlos, can we work around this issue?
[08:18] <kiko> what query is that one?
[08:18] <carlos> kiko, well, as far as I know, the problem was an index that confused postgres parser so the queries take too long  to execute
[08:19] <carlos> kiko, he told me that he removed the index and it's not a problem anymore
[08:19] <kiko> we still have a problem apparently
[08:19] <carlos> kiko, before that, last thing he told me to fix it (Before remove the index) was to remove a LIMIT 1 from the query that produces it
[08:20] <kiko> carlos, can you tell me where to look so I can see what the problem is?
[08:20] <carlos> just a second...
[08:20] <kiko> bradb, I forgot to say, did you run pyflakes on the files you changed to make sure imports were correct?
[08:20] <carlos> https://chinstrap.ubuntu.com/~dsilvers/paste/filevre5Mc.html
[08:20] <carlos> kiko, that's the method that stub told me that seems to take too long
[08:21] <carlos> kiko, but we didn't change it recently
[08:21] <bradb> kiko: nope. had no idea that we were meant to do that.
[08:21] <kiko> sounds unlikely, doesn' it?
[08:21] <kiko> bradb, well, it will help you catch common programming errors.
[08:22] <carlos> the main problem seems to be that it joins 4 million rows with another similar amount, and then filters out getting all related with one pofile
[08:22] <bradb> in what way does it improve upon pylint?
[08:22] <bradb> (not that i ran pylint either, but was just curious)
[08:22] <kiko> bradb, it's simpler and faster
[08:22] <kiko> running pylint is an obvious plus
[08:23] <kiko> carlos, can you ask salgado to issue the query on staging to see if it does take that long to run?
[08:23] <carlos> I can do it directly, just a second...
[08:23] <salgado> I don't have access to staging
[08:23] <kiko> or production if we are brave
[08:23] <salgado> neither on production
[08:24] <salgado> stub closed the backdoor I was using. 
[08:24] <carlos> bastard! :-P
[08:24] <salgado> "backdoor", even
[08:25] <kiko> carlos, tell me the results
[08:28] <carlos> https://chinstrap.ubuntu.com/~dsilvers/paste/file2YY82e.html
[08:28] <kiko> carlos, and the select itself?
[08:28] <kiko> how long does it take to run
[08:29] <carlos> https://chinstrap.ubuntu.com/~dsilvers/paste/filer7AkKK.html
[08:29] <bradb> SteveA_: bradb@oxygen:~/launchpad/lib/canonical/launchpad $ find . -name "*.py" | xargs pylint.python2.4 --disable-all --enable-miscellaneous=y <= I encourage you to try that.
[08:30] <bradb> by the looks of it we have way over a hundred XXX/FIXME's/TODO's in our code
[08:31] <bradb> *must* absolutely, even
[08:34] <carlos> kiko, any idea? I cannot think on an easy fix for that query other that add a cached value and that's not trivial
[08:35] <carlos> and as I said, that method is not new, it has been there since long ago
[08:35] <kiko> carlos, I mean
[08:35] <kiko> how long does the /query/ take to run?
[08:35] <kiko> not the explain
[08:35] <carlos> kiko, how can I rate it?
[08:35] <kiko> just run it!
[08:35] <kiko> it will say how long it took (IIRC)
[08:35] <kiko> otherwise look at the pgsql log
[08:36] <carlos> kiko, I get the answer altmost at the same time I press enter
[08:36] <carlos> so it's not slow at all
[08:38] <carlos> kiko, https://chinstrap.ubuntu.com/~dsilvers/paste/fileEzfSVQ.html
[08:39] <carlos> kiko, and https://launchpad.ubuntu.com/distros/ubuntu/breezy/+translations (the link I think you gave me like the last one that was visited) loads really fast
[08:45] <carlos> kiko, I need to leave to bring the car to my parent's job, will be back in about 30-45 minutes. At this moment I don't see anything I can fix without some extra information. A query that takes 1second to run does not seems like the problem here, we are missing something
[08:45] <kiko> then that's probably not the problem :-/
[08:45] <kiko> okay.
[08:45] <carlos> btw, we could apply the change jamesh suggested this morning
[08:45] <kiko> ah!
[08:45] <kiko> one sec.
[08:45] <carlos> so we raise exceptions if a query tooks too long
 There are also a load of po-attach processes hung trying to call sendmail
[08:45] <kiko> carlos, could /that/ be the problem
[08:46] <carlos> kiko, hmm, not sure, does it affects launchpad?
[08:46] <kiko> not sure either
[08:47] <kiko> perhaps, because don't scripts use the lp machinery?
[08:47] <carlos> and I suppose stub means poimport
[08:47] <kiko> hmmm
[08:47] <carlos> becasue the attach one does not uses sendmail...
[08:47] <kiko> I don't quite understand the problem and stub was too busy to be helpful.
[08:47] <carlos> kiko, the poimport script is broken without a patch that will be cherrypicked by lifeless tomorrow
[08:47] <kiko> ah well
[08:47] <kiko> aye.
[08:47] <carlos> so it can be disabled
[08:48] <carlos> if you think it's the cause of all our problems
[08:48] <carlos> until tomorrow
[08:48] <kiko> I don't, really, but I don't have a lot to go on. 
[08:48] <carlos> me neither
[08:48] <kiko> salgado, can you try uncovering more details? the postgres log may contain hints
[08:49] <salgado> kiko, I don't have access to the postgres logs
[08:49] <carlos> kiko, I think we should get someone from outside .au that gets some extra rights in our servers, without lifeless and stub  we are really fucked
[08:50] <kiko> yeah, it's a suicide mission
[08:50] <kiko> okay, thanks for the help
[08:50] <carlos> kiko, It's my job ;-)
[09:02] <kiko> bradb, what's the reason to use a staticmethod instead of a regular method, if we are calling it from an instance? performance?
[09:04] <bradb> kiko: dunno if there's a good reason to use them in lp code. i never do.
[09:05] <bradb> (i can't guarantee that i've never written a staticmethod once in lp code, but if i have, it must have been done blindfolded.)
[09:19] <salgado> aha. launchpad is gone(again)?
[09:20] <bradb> yeppers
[09:21] <bradb> it went for a beer with pqm, i think
[09:25] <salgado> nothing unusual in the logs that I have access. the same failure I pasted before
[09:33] <kiko> salgado, not even a while back
[09:33] <kiko> do you have permissions to strace or gdb?
[09:34] <salgado> no, the process is owned by the launchpad user
[09:40] <bradb> SteveA_: i've got an addform with custom widgets, like:
[09:40] <bradb>         <browser:widget
[09:40] <bradb>            field="private"
[09:40] <bradb>            class="zope.app.form.browser.CheckBoxWidget"
[09:40] <bradb>            extra="tabindex=3" />
[09:41] <bradb> how do i set properties of the "Add" button on the form though? i want to change its tabindex.
[09:41] <kiko> bradb, I have a question for you
[09:42] <kiko> you know your suggestion for the person portlet, where you asked me to say "First reported by" and "Reported in XXX by"?
[09:42] <kiko> how do I know when it's running here or there?
[09:42] <kiko> i.e. in the bug or in the task?
[09:43] <bradb> it might be clearer as two portlets, in that case
[09:44] <kiko> bradb, hmmm. there's a problem, though -- the contextname may be kind of long. what dya think?
[09:44] <bradb> yeah, that's a concern
[09:45] <kiko> let's leave that for later then.
[09:46] <kiko> bradb, interesting -- is there no way of finding out who reported a task today?
[09:47] <bradb> kiko: there is on the task page. it's one of the things i added during DBABT
[09:48] <bradb> the portlet in the top right lists the context specific details (including the date reported in that context, etc.)
[09:48] <bradb> (because that's the date that matters for things like whine mail, etc.)
[09:49] <kiko> I see
[09:49] <kiko> nasty redundancy there
[09:49] <kiko> I'll look into it later
[09:49] <bradb> redundancy in what?
[09:50] <bradb> ZPT-level redundancy, you mean?
[09:50] <kiko> no, in terms of information
[09:50] <kiko> bug #2 in ubuntu
[09:51] <kiko> occuring in Ubuntu
[09:51] <kiko> reporter: sample person
[09:51] <kiko> reported by: sample person
[09:51] <kiko> salgado, is there a trivial way of listing just the files changed? baz status tells me too much
[09:52] <bradb> kiko: interesting, when i showed mark that page, he noted that he wanted it to be ABSOLUTELY CLEAR that you're looking at bug #42 in <whatever> context. he didn't think the page i showed him had been doing that clearly enough, despite the fact that the context information was repeated in like 7 different parts of the UI.
[09:52] <jblack> It seems as if launchpad has been down for a long while again.
[09:52] <kiko> it's just presented poortly, I think
[09:52] <kiko> jblack, it's gonna be down for the next 4h or until we get elmo to kick it
[09:53] <jblack> gah! 
[09:53] <kiko> blame travel and the fact that our only admins live in .au
[09:53] <kiko> if it's urgent, wake rob up
[09:53] <kiko> :-(
[09:53] <kiko> it's like 6am there
[09:53] <bradb> jblack: considering pqm is dead (as usual), maybe it's worth waking him up?
[09:54] <jblack> Rob will just have to understand that out of the eight hours that I"ve worked, its been down for 4 or 5 of it? 
[09:54] <kiko> jblack, is there a trivial way of listing just the files changed? baz status tells me too much
[09:54] <kiko> jblack, I guess. give him a call
[09:54] <jblack> depends on what you want. baz status has several options. 
[09:54] <jblack> you may be looking for --lint, or baz diff
[09:55] <kiko> I just want to list the files changed
[09:55] <kiko> nothing else
[10:05] <kiko> okay, found a way
[10:34] <salgado> lifeless, also, pqm seems to be hung on bradb's branch
[10:34] <lifeless> --- SIGTERM (Terminated) @ 0 (0) ---
[10:34] <lifeless> getpid()                                = 3332
[10:34] <lifeless> rt_sigaction(SIGTERM, {0x80e8880, [] , 0}, {0x80e8880, [] , 0}, 8) = 0
[10:34] <lifeless> sigreturn()                             = ? (mask now [] )
[10:34] <lifeless> futex(0x82928a0, FUTEX_WAIT, 0, NULL)   = -1 EINTR (Interrupted system call)
[10:34] <lifeless> --- SIGTERM (Terminated) @ 0 (0) ---
[10:34] <lifeless> getpid()                                = 3332
[10:34] <lifeless> rt_sigaction(SIGTERM, {0x80e8880, [] , 0}, {0x80e8880, [] , 0}, 8) = 0
[10:34] <lifeless> sigreturn()                             = ? (mask now [] )
[10:34] <lifeless> futex(0x82928a0, FUTEX_WAIT, 0, NULL)   = -1 EINTR (Interrupted system call)
[10:34] <lifeless> thats a strace of the librarian
[10:34] <lifeless> in the test suite
[10:35] <lifeless> after I 'kill XXXX' it
[10:35] <kiko> good ole futex
[10:35] <kiko> lifeless, I'm a /lot/ more concerned with launchpad.
[10:36] <lifeless> looking
[10:37] <lifeless> did someone try to wake me ?
[10:38] <kiko> I'm not entirely sure, I suggested jblack did
[10:38] <kiko> we really need to get an admin in this timezone
[10:40] <carlos> kiko, did you find the problem? is it related with Rosetta?
[10:41] <lifeless> carlos: almost certainly, lps threads are all blockd on queries
[10:43] <lifeless> carlos:  SELECT POSubmission.id, POSubmission.origin, POSubmission.person, POSubmission.pluralform, POSubmission.datecreated, POSubmission.potranslation, POSubmission.pomsgset, POSubmission.validationstatus FROM POMsgSet, POSubmission WHERE  
[10:43] <lifeless> is the culprit
[10:44] <carlos> lifeless, I executed that query on staging
[10:44] <carlos> and it took only 1 minute
[10:44] <carlos> sorry
[10:44] <carlos> 1 secon
[10:44] <carlos> d
[10:44] <salgado> but this query is truncated, as stuart pointed out
[10:45] <carlos> salgado, he found a query that was not truncated
[10:45] <lifeless> this is being run hundreds of thousands of times
[10:45] <lifeless> 1 second is probably 10 times longer than we can support
[10:45] <kiko> lifeless, who is running this query hundreds of thousands of time, can you find out?
[10:45] <lifeless> kiko: launchpad_prod
[10:45] <kiko> hihi
[10:45] <kiko> lifeless, I mean, what codepath is being triggered (and by whom)
[10:46] <lifeless> kiko: no
[10:46] <kiko> is it impossible to find out?
[10:46] <lifeless> kiko: for surety yes. But I think, like stub said, its google.
[10:47] <lifeless> this time its yahoo
[10:47] <lifeless> in all probability.
[10:47] <kiko> yahoo is hitting hundreds of thousands of pages?
[10:47] <kiko> or one page is generating hundreds of thousands of queries.
[10:47] <lifeless> won't know until it completes
[10:47] <lifeless> and as I'm about to revoke permissions ...
[10:49] <jblack> lifeless: lp has been down all day. :( 
[10:49] <lifeless> jblack: don't worry about it.
[10:49] <kiko> lifeless, won't the failure make it clear?
[10:49] <kiko> (who was triggering the issue?)
[10:49] <jblack> worried? me? worry? I never worry! 
[10:49] <kiko> i.e. we'll get millions of errors in the log?
[10:49] <lifeless> kiko: no
[10:50] <lifeless> kiko: we'll get get errors from all rosetta users
[10:50] <lifeless> oh bah, stub , bah.
[10:51] <kiko> lifeless?
[10:55] <lifeless> kiko: stuff that we need for db maintenance is currently just checked out as stub
[10:55] <lifeless> kiko: so I need to check it out myself before I can run the update
[10:56] <bradb> lifeless: is it safe to submit merge requests to pqm again?
[10:56] <lifeless> bradb: it was never unsafe
[10:56] <bradb> you wouldn't be saying that if you wore my shoes ;)
[10:56] <lifeless> bradb: the queue was stalled because the librarian had crashed
[10:57] <lifeless> so the test suite deadlocked on it AFAICT
[10:57] <carlos> excuse me I had a phone call
[10:58] <carlos> ok, I will take a look at it, but I don't see an easy way to improve it other than caching the result value and it will not be a trivial change
[10:59] <lifeless> carlos: can we just make the page not listed such that google/yahoo find it ?
[10:59] <carlos> I mean, I can do it for tomorrow, but will touch several files and I prefer if it's reviewed before cherrypick it into production
[10:59] <lifeless> carlos: i.e. only registered users get any suggestions, or ..
[10:59] <carlos> lifeless, it's not just suggestions
[10:59] <carlos> lifeless, could we ban google and yahoo bots?
[10:59] <carlos> robots.txt should do it
[10:59] <carlos> until we fix the bug
[11:00] <lifeless> well, whatever it is - its probably ok-but-not-optimal for end users, but killer for bots
[11:00] <lifeless> right, what pattern should I put in there
[11:00] <lifeless> :/
[11:01] <carlos> User-agent: *
[11:01] <carlos> Disallow: /
[11:01] <carlos> that should ban all robots
[11:01] <lifeless> uhm, ban them all you mean. erm
[11:01] <carlos> http://www.searchengineworld.com/robots/robots_tutorial.htm
[11:02] <lifeless> that seems fairly harsh
[11:03] <carlos> lifeless, it will be only until tomorrow
[11:03] <carlos> while I prepare a fix, it gets reviewed and we cherrypick it
[11:03] <lifeless> btw
[11:03] <lifeless> tible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)"
[11:03] <lifeless> 127.0.0.1 - Anonymous [14/Jul/2005:21:35:39 +0100]  "GET /++vh++https:launchpad.ubuntu.com:443/++/token/djCg0b1v9Gjcrb1ch6WJ HTTP/1.1" 303 2970 "" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050601 Firefox/1.0.4 (Ubuntu package 1.0.4)"
[11:03] <lifeless> launchpad@macquarie ~ $ tail dists/launchpad/launchpad-access.log  -f
[11:03] <lifeless> 127.0.0.1 - 94 [14/Jul/2005:21:35:37 +0100]  "GET /++vh++https:launchpad.ubuntu.com:443/++/people/name94 HTTP/1.1" 200 5939 "https://launchpad.ubuntu.com/malone/bugs/1243" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050405 Firefox/1.0 (Ubuntu package 1.0.2)"
[11:03] <lifeless> 127.0.0.1 - Anonymous [14/Jul/2005:21:35:37 +0100]  "GET /++vh++https:launchpad.ubuntu.com:443/++/robots.txt HTTP/1.1" 200 236 "" "Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)"
[11:03] <lifeless> 127.0.0.1 - Anonymous [14/Jul/2005:21:35:37 +0100]  "GET /++vh++https:launchpad.ubuntu.com:443/++/rosetta/products/wordpress/wordpress-1.5/+translate?languages=fr_CH HTTP/1.1" 500 4357 "" "Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)"
[11:04] <lifeless> 127.0.0.1 - Anonymous [14/Jul/2005:21:35:37 +0100]  "GET /++vh++https:launchpad.ubuntu.com:443/++/robots.txt HTTP/1.1" 200 236 "" "Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)"
[11:04] <lifeless> 127.0.0.1 - Anonymous [14/Jul/2005:21:35:37 +0100]  "GET /++vh++https:launchpad.ubuntu.com:443/++/ HTTP/1.1" 200 5174 "" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4"
[11:04] <lifeless> 127.0.0.1 - Anonymous [14/Jul/2005:21:35:38 +0100]  "GET /++vh++https:launchpad.ubuntu.com:443/++/people/ubuntumembers HTTP/1.1" 200 5232 "" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050517 Firefox/1.0.4 (Debian package 1.0.4-2)"
[11:04] <lifeless> 127.0.0.1 - Anonymous [14/Jul/2005:21:35:38 +0100]  "GET /++vh++https:launchpad.ubuntu.com:443/++/rosetta/products/wordpress/wordpress-1.5/+translate?languages=it_IT HTTP/1.1" 500 4357 "http://www.fogliata.net/archives/2005/02/17/localizzazione-italiana-per-wordpress-15/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)"
[11:04] <lifeless> 127.0.0.1 - Anonymous [14/Jul/2005:21:35:39 +0100]  "GET /++vh++https:launchpad.ubuntu.com:443/++/malone/bugs/1399 HTTP/1.1" 200 9211 "" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
[11:04] <lifeless> 127.0.0.1 - Anonymous [14/Jul/2005:21:35:39 +0100]  "GET /++vh++https:launchpad.ubuntu.com:443/++/rosetta/products/wordpress/wordpress-1.5/+translate/+login?languages=es_ES HTTP/1.1" 200 7083 "" "Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)"
[11:04] <lifeless> 127.0.0.1 - Anonymous [14/Jul/2005:21:35:39 +0100]  "GET /++vh++https:launchpad.ubuntu.com:443/++/token/djCg0b1v9Gjcrb1ch6WJ HTTP/1.1" 303 2970 "" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050601 Firefox/1.0.4 (Ubuntu package 1.0.4)"
[11:04] <lifeless> that should give you some hints
[11:05] <carlos> those links are to protected things...
[11:06] <lifeless> those pages completed ok
[11:06] <lifeless> but I imagine it was traversing out from them
[11:06] <lifeless> I can't find a robots.txt in the source, do we have one ?
[11:07] <SteveA_> for the public zope site
[11:07] <SteveA_> they use several app servers
[11:07] <SteveA_> and have one that they always sent robots to
[11:07] <SteveA_> so, robots just slow each other down
[11:07] <lifeless> right
[11:07] <lifeless> we can do that once we get the load balancing online (if pound supports that, otherwise we might need to use squid ;0)
[11:08] <SteveA_> i know, let's rewrite squid using twisted
[11:08] <SteveA_> it won't take long
[11:08] <lifeless> if I am the one doing it, sure :)
[11:08] <SteveA_> DOIT
[11:08] <lifeless> DONE
[11:08] <kiko> vf
[11:09] <lifeless> but I had it on my ramdisk, which I just rebooted. soh
[11:09] <SteveA_> i'm off to bed shortly, up for a taxi at 6.20.  just copying over my stuff onto the laptop, and grabbing the latest from RF.
[11:09] <kiko> SteveA_, ping?
[11:09] <kiko> just one question
[11:09] <lifeless> happy travels
[11:10] <kiko> SteveA_,  is there any reason for _linkify_substitution to be a staticmethod?
[11:10] <SteveA_> i'll be around for a while yet -- baz takes so long on my laptop
[11:10] <lifeless> carlos: what I want to know is why it suddently got bad ?
[11:10] <SteveA_> kiko: yes.  it needn't be anything but.
[11:10] <kiko> SteveA_, and bonus question: are you okay with me splittine that into _linkify_bug and _linkify_url?
[11:10] <SteveA_> kiko: how do you mean?
[11:10] <kiko> SteveA_, a reason other than that.
[11:11] <kiko> the method currently does: if a: ... long section of code elif b: ... long section of code
[11:11] <SteveA_> how do you mean, splitting it into linkify bug and linkify url?
[11:11] <kiko> I'd rather they were separate for maintenence reasons
[11:11] <SteveA_> you want one method that calls one of two others?
[11:11] <kiko> right
[11:12] <kiko> hmmm
[11:12] <kiko> we could also use separate regular expressions, I imagine
[11:12] <SteveA_> no
[11:12] <kiko> no?
[11:12] <SteveA_> don't use separate regexes
[11:12] <SteveA_> it isn't a very long method, if you take out the comments
[11:13] <lifeless> we shouldn't use comments, they make the code too long
[11:13] <carlos> lifeless, no idea
[11:13] <SteveA_> there's about 8 lines of code for linkifying urls
[11:13] <SteveA_> and about 14 for linkifying bugs
[11:13] <kiko> ideally a callable should do one thing
[11:13] <SteveA_> i say leave it as it is
[11:13] <lifeless> carlos: well, what changed in rosetta from the last release to this? Was it adding a link as part of googleification ?
[11:14] <kiko> SteveA_, what's the problem with using separate regexps?
[11:14] <SteveA_> jamesh already demonstrated
[11:14] <carlos> lifeless, I didn't change anything, I suppose it's related with Mark's changes
[11:14] <kiko> I see
[11:15] <carlos> but that method is not new at all
[11:15] <lifeless> sabdfl kills launchpad news at 11.
[11:15] <carlos> so I suppose that for any reason it's not called a lot
[11:15] <SteveA_> kiko: save it until i'm in brazil
[11:15] <SteveA_> we can look through it then much more easily
[11:15] <carlos> lifeless, do you need anything from me (other than the patch to reduce the time of that method)
[11:15] <carlos> ?
[11:15] <kiko> the issue is a URL containing "bug XXX", i guess (which is impossible but..)
[11:16] <kiko> ah,
[11:16] <kiko> URLs to malone bugs should also be linkified :)
[11:16] <kiko> (specially)
[11:16] <kiko> that throws a twist in.
[11:17] <bradb> SteveA_: i have an addform with custom widgets A, B and C. the tab order of A, B and C is 1, 2 and 3, respectively. how do i set the tabindex of the "Add" button itself to be 4, so that when I tab out of widget C, I landed on the "Add" button?
[11:17] <SteveA_> bradb: i have no idea.
[11:17] <SteveA_> i think there's a way to override how the button is presented
[11:18] <SteveA_> dunno what it is, without going and reading the source
[11:18] <kiko> yeah.
[11:18] <kiko> we'll let you read it for free bradb 
[11:18] <bradb> HEH
[11:18] <lifeless> you are so full of compassion
[11:19] <bradb> lost in the bowels of Z3...he must be working on something really deep and complex! what do you mean "all he wanted to do was change the tabindex of a button?"
[11:19] <kiko> welcome to the world of autogen forms
[11:20] <bradb> it takes forever to hand-write forms though too, unfortunately
[11:21] <SteveA_> i thought that's what outsourcing was all about
[11:21] <bradb> particularly with error handling, value persistence, consistent presentation and labelling, etc.
[11:23] <lifeless> carlos: could https://launchpad.ubuntu.com/distros/ubuntu/hoary/+translations be the problem ?
[11:24] <lifeless> oh hohoho
[11:25] <lifeless> launchpad doesn't recover from db bounces yet
[11:28] <lifeless> ok
[11:28] <lifeless> rosetta pomsgset disabled
[11:28] <lifeless> lp will no longer go down
[11:36] <cprov> ehh? freenode kicks ass 
[11:53] <bradb> lifeless: er, wait, did you bounce pqm earlier or not then? i got the impression that you did, but it's hung again.
[11:54] <SteveA_> kiko: see you tomorrow!
[11:56] <lifeless> bradb: I did, new hang
[11:56] <bradb> ah
[11:56] <lifeless> python cronscripts/rosetta-poimport.py -q was hung and needed a kill -9
[11:57] <bradb> lifeless: is there anyway pqm can run the request command in a little box, and for us to be a given a big red button that can tell pqm to "reset" itself, which includes completely resetting the box to its default state?
[11:58] <bradb> s/request/requested/
[11:58] <bradb> i'm not sure if a chroot jail is usable for this purpose or not
[11:58] <lifeless> bradb: please give me feedback on my PqmRobustness BrainDump