[00:49] <nigelb> Morning!
[00:52] <nigelb> StevenK: haha, airline staff with a sense of humour! Nice :)
[01:15] <abentley> jelmer: sure.
[01:59] <lifeless> wgrant: is hotness qa-ok ?
[02:39] <wgrant> lifeless: No idea, been doing other stuff since it appeared on qas.
[02:39] <wgrant> Will QA now.
[02:42] <wgrant> lifeless: Is the bounty removal not done?
[02:42] <wgrant> IIRC all that was left was the DB schema, which I removed months ago.
[02:42]  * wgrant greps
[02:42] <wgrant> Nope, all gone.
[02:52] <wgrant> lifeless: Yes
[02:56] <wgrant> Actually
[02:56] <wgrant> Should do ppa/ftpmaster tonight.
[02:57] <wgrant> Ursinha's DB patch and garbo job tomorrow
[02:57] <wgrant> Then EmailAddress.account dies on whatever the day after that is.
[03:02] <wgrant> Lies.
[03:17] <StevenK> Hm?
[03:22] <wgrant> canonical/launchpad/mars :)
[03:24] <StevenK> Ahh
[03:24] <StevenK> wgrant: I agree with ppa/ftpmaster tonight for FDT, FWIW.
[03:26] <wgrant> !FDT
[03:26] <wgrant> But yes
[03:28] <StevenK> The FDT window, you pendant. :-P
[03:30] <wgrant> fdt refers to the DB update. We've had mistakes in the past around this confusion.
[03:31] <wgrant> So we need to be clear.
[03:35] <wgrant> lifeless: Can you remind me why we can't use GIN yet?
[03:36] <nigelb> wgrant: OCRing today?
[03:37] <wgrant> Oh, bah, it's Tuesday now.
[03:37] <wgrant> Maybe.
[03:37] <StevenK> Haha
[03:37] <nigelb> Did you work through the night?
[03:37] <wgrant> nigelb: rvba reviewed your branch last night, AFAICT.
[03:37] <wgrant> No
[03:37] <nigelb> He did?
[03:38] <nigelb> bah
[03:39] <nigelb> dammit, how did I miss that email :|
[03:40] <nigelb> Interesting. My email doesn't think Lp reviews are priority anymore.
[03:40]  * nigelb changes that.
[03:42] <lifeless> wgrant: table scans
[03:42] <lifeless> StevenK: 'pedant'
[03:43] <nigelb> I did wonder about pendant :P
[03:43]  * StevenK hits lifeless's engine with a baggage cart, stranding him in Heathrow.
[03:43] <nigelb> heh
[03:44] <wgrant> lifeless: Confused
[03:44] <wgrant> Clearly the index is not being used properly if it invokes a table scan.
[03:45] <wgrant> Ah, it doesn't support full index scans, I see.
[03:47] <wgrant> Bug #119780 ftr
[03:47] <_mup_> Bug #119780: bug comment full text search is disabled - GIN indices in pg 8.2 do not support table scans <lp-bugs> <search> <Launchpad itself:Fix Released by stub> < https://launchpad.net/bugs/119780 >
[03:59]  * StevenK stares at Storm
[04:00] <StevenK> The validator insists 'depends-on+987' is not a valid name.
[04:00] <wgrant> "The validator"?
[04:01] <StevenK> valid_name SQL function
[04:02] <wgrant> Ah, so nothing to do with Storm.
[04:02] <wgrant> You sure you don't have a newline or space or something in there?
[04:03] <StevenK> wgrant: http://pastebin.ubuntu.com/807006/
[04:03] <wgrant> Oh
[04:03] <wgrant> valid_tag is not valid_name
[04:04] <StevenK> CONSTRAINT valid_tag CHECK (valid_name(tag))
[04:04] <wgrant> Ah, but it is.
[04:05] <wgrant> Perhaps it wants a list?
[04:05] <wgrant> What's the SQL that it generates?
[04:05] <wgrant> I suspect it may be splitting on + or similar
[04:08] <StevenK> It uses for tag in tags, which does it per char for a string
[04:08] <StevenK> Which is ... handy
[04:17] <StevenK> NoCanonicalUrl: No url for None because None broke the chain.
[04:17] <StevenK> Bah
[05:12] <wallyworld> bollocks. latest NDT breaks javascript on merge proposal pages
[05:15] <wallyworld> and also on code index page
[05:15] <nigelb> whats's NDT?
[05:16] <wgrant> nigelb: nodowntime deployment
[05:16] <wgrant> wallyworld: Hm, what's the impact
[05:16] <wgrant> ?
[05:16] <wgrant> MP pages don't have much non-beta JS
[05:16] <nigelb> AHA.
[05:17] <wgrant> And code index JS is not used much
[05:17] <wallyworld> wgrant: the code index breaks such that the branch filter drop downs don't work
[05:17] <wgrant> Indeed.
[05:17] <wallyworld> wgrant: it's becuase a mochikit method connect() is being used in the tal
[05:17] <wgrant> I suspect that is used little, however. If the fix is simple, I suggest fixing rather than rolling back.
[05:17] <wallyworld> so i can work on that
[05:18] <wallyworld> haven't looked at the mp breakage yet
[05:18] <wallyworld> yes, i agree we should try and fix
[05:19]  * wallyworld hates stupid embedded javascript in the tal page templates :-(
[05:20] <wgrant> MP JS seems to be entirely broken, but the fallbacks all work fine.
[05:22] <wallyworld> yep, the js breaks early on in the load/parsing phase
[05:24] <wgrant> Ah
[05:24] <wgrant> It looks for div#add-comment-form
[05:24] <wgrant> But on MPs it's form#add-comment-form
[05:29] <wgrant> I think bug commenting is broken too :)
[05:29] <wgrant> lib/lp/app/javascript/comment.js has an undefined trim()
[05:29] <wgrant> Perhaps it means Y.Lang.trim
[05:30] <wallyworld> wgrant: that's fallout from deryck's work to sort out bug comments last week
[05:30] <wallyworld> i can fix that also
[05:30] <wgrant> But we need to revert
[05:30] <wgrant> spm: ^^
[05:30] <wgrant> Since it breaks after the fallback is disabled.
[05:30] <spm> revert what/where?
[05:30] <StevenK> Revert the NDT we just did
[05:31] <StevenK> Just the appservers is fine
[05:31] <wgrant> Right.
[05:33] <wgrant> wallyworld: http://paste.ubuntu.com/807058/ fixes the bug comment thing. It's the last trim() callsite AFAICT.
[05:33] <wallyworld> wgrant: otp, just give me a sec
[05:35] <wallyworld> wgrant: cool. i'm currently fixing the remaining uses of mochikit connect
[05:36] <wallyworld> then there's just the form#add-comment vs div#add-comment thing
[05:36] <wgrant> MPs fixed
[05:36] <wgrant> Yeah
[05:36] <wgrant> Just s/div// fixes it
[05:36] <wgrant> Looking for other breakage
[05:36] <wallyworld> wgrant: no, the div was put there to make something else work
[05:37] <wallyworld> so the solution is not as simple as s/div//
[05:37] <wallyworld> i'll look into it
[05:37] <wgrant> -        this.comment_input = Y.one('[id="field.comment"]');
[05:38] <wgrant> +        this.comment_input = Y.one(
[05:38] <wgrant> +            'div#add-comment-form [id="field.comment"]');
[05:38] <wgrant> is the relevant diff
[05:38] <wgrant> The div was not added -- the whole first selector was.
[05:39] <wgrant> We also have something on the MP page trying to set patting-bottom
[05:39] <wgrant> But I assume that's unrelated.
[05:41] <wallyworld> yes, any arse patting is unrelated
[05:45] <StevenK> wgrant: http://pastebin.ubuntu.com/807064/ :-(
[05:45] <wgrant> Work out what the object is.
[05:46] <wgrant> Debuggers are handy :)
[05:46] <wgrant> AND IDES ARE NOT MANDATORY
[05:46] <spm> itt, wgrant admits to using ed for all his editing needs
[05:46] <StevenK> Haha
[05:47] <wgrant> Nah, was an inb4 pycharm from wallyworld.
[05:47] <wallyworld> not mandatory but a shit load more productive for anything but simple debugging work
[05:48] <StevenK> wgrant: Sadly obj is None
[05:49] <wgrant> StevenK: Right -- you'll probably want a conditional breakpoint on the parent calculation
[05:49] <StevenK> Breaking in canonical_urldata_iterator() the first obj is a IBug
[05:50] <wgrant> Do you know if that's the same call?
[05:50] <wgrant> The most common thing to generate that error is a bugmessage.
[05:50] <wgrant> Not a bug.
[05:53] <StevenK> Grabbing obj from the iterator gives a whole bunch of things then:
[05:53] <StevenK> <BugTask for bug 16 on <Product at 0xff1b890>>
[05:53] <StevenK> None
[05:53] <_mup_> Bug #16: "Swedish" and "Swedish (Sweden)" should be the same language <lp-translations> <Launchpad itself:Fix Released by daf> < https://launchpad.net/bugs/16 >
[05:53] <spm> wgrant: reverted to 14664 on the appservers
[05:53] <StevenK> spm: Thanks!
[05:53] <wgrant> spm: Thanks
[05:53] <StevenK> Bloody MochiKit
[06:01] <StevenK> wgrant: Don't get it :-(
[06:02] <wgrant> StevenK: Trace through where it's obtaining the None.
[06:03] <StevenK> wgrant: The menu code is implicated. Which hooks into TAL, and debugging that is madness.
[06:05] <StevenK> wgrant: Since it looks like MenuBase._init_link_data() is called twice, once where self.context is Product, and again where it is None
[06:09] <StevenK> Calling <lp.bugs.browser.bug.BugContextMenu object at 0x1036e810>.initLink('affectsmetoo', 'http://launchpad.dev/')
[06:14] <StevenK> And that menu's context is None, which gets into canonical_url
[06:16] <wgrant> wallyworld: How go the fixes? We should either fix it all or readd mochikit and fix the div#comment-add-form thing within 45 minutes.
[06:17] <wgrant> Or we'll miss the next buildbot run.
[06:17] <wallyworld> wgrant: i thought we were doing a rollback?
[06:17] <StevenK> We rolled back prod
[06:17] <StevenK> Not the rev
[06:17] <wgrant> wallyworld: Production is reverted, but all deployments are now blocked.
[06:17] <wgrant> And there is some very interesting stuff which now cannot be deployed.
[06:18] <wgrant> => fixing this is top priority
[06:18] <wallyworld> that's what i'm doing
[06:18] <StevenK> wgrant: How does this menu stuff work? :-(
[06:18] <wgrant> StevenK: Not very well
[06:19] <wgrant> StevenK: But you're probably instantiating the view incorrectly, or using the wrong layer.
[06:19] <wallyworld> but i have to refactor to make it yui compatible, and that has issues the way the js is embedded
[06:20] <wgrant> If it's going to go past EOD, we need to revert the relevant revisions.
[06:20] <wgrant> I think all but one issue is fixed by readding mochikit.
[06:25] <wallyworld> i'll get it fixed soon
[06:25] <StevenK> wgrant: Looks the same as everything else in that test?
[06:33] <rick_h__> wallyworld: the JS stuff ok? Anything you need a hand with real quick?
[06:34] <wallyworld> rick_h__: no, i've got it under control. just mindless refactoring. thanks for asking. only a couple of places left to change
[06:34] <rick_h__> wallyworld: ok cool. back to bed then. Thanks!
[06:34] <wallyworld> see ya
[06:45]  * StevenK stabs this test
[07:04] <lifeless> poolie: another interesting thing to look at - https://secure.phabricator.com/
[07:04] <wgrant> Why do all of their buttons look like Facebook?
[07:05] <lifeless> because facebook made it ?
[07:05] <wgrant> Ah
[07:05] <lifeless> http://www.phabricator.com/docs/phabricator/
[07:07] <wgrant> wtf
[07:07] <wgrant> cannot access it at all without logging in.
[07:08] <lifeless> http://phabricator.org/ has an overview
[07:08] <poolie> that's a bit creepy
[07:08] <wgrant> It's a bit Facebook.
[07:08] <poolie> > Facebook engineers rave about Phabricator, describing it with glowing terms like "okay" and "mandatory".
[07:10] <poolie> nice
[07:10] <poolie> yeah looks a bit locked to their approach
[07:11] <poolie> i wish lp's bug search ui was a bit like  https://secure.phabricator.com/maniphest/?g=o
[07:12] <wallyworld> wgrant: https://code.launchpad.net/~wallyworld/launchpad/more-mochikit-fallout/+merge/88814
[07:13] <wgrant> poolie: I think a less crap search UI can be built on top of the new sort UI.
[07:13] <nigelb> heh, I search and I see all of you on top :)
[07:13] <wgrant> (in 2015)
[07:13] <poolie> i was thinking about eventually doing power search
[07:14] <poolie> ie "assigned:wgrant status:inprogress"
[07:14] <nigelb> wgrant: (in 2015). Hah.
[07:14] <poolie> .. i feel i would just about know how to do it
[07:14] <poolie> not at the top of my queue
[07:14] <wgrant> poolie: I think that was proposed in 2005
[07:14] <poolie> yes, i know
[07:14] <nigelb> One of the things I like about bugzilla is awesome search.
[07:14] <poolie> by tim and me, in at least one of the proposals
[07:15] <poolie> wgrant, however search is timing out so much of the time.. i think that ought to be fixed first
[07:15] <wgrant> wallyworld: Isn't LPS deprecated?
[07:15] <wgrant> wallyworld: Or did you renege on that?
[07:15] <poolie> it would also be neat, though less urgent, to do some kind of machine-learning-based estimation of how far in the future a bug will be closed
[07:15] <wgrant> poolie: Bah, it's only like 90% of our timeouts.
[07:15] <wallyworld> wgrant: it is, but i thought we were still using it until we cut over. i'll check
[07:16] <wgrant> wallyworld: I really have no idea. I just heard discussion last week.
[07:16] <wallyworld> wgrant: we use it for now
[07:16] <wgrant> kk
[07:16] <lifeless> poolie: that estimate is easy: never; correct for 99% of bugs :P
[07:17] <poolie> haha
[07:17] <wallyworld> wgrant: it means there will be a little cleanup when the new stuff needs to get merged ie one mor ecase to port
[07:17] <wgrant> wallyworld: So, MP pages now turn green, bug commenting works, and branch filtering/sorting works?
[07:17] <poolie> but, not true in at least some contexts
[07:17] <poolie> a bit over half of valid bzr bugs have been fixed
[07:17] <wgrant> There's also an XSS you can fix here, if you want :)
[07:17] <wallyworld> wgrant: yes. with mp, i created one and ensured i could add a comment
[07:18] <wgrant> Oh, in fact that's the one that was reported a couple of weeks back.
[07:18] <wallyworld> wgrant: point me to the xss
[07:18] <wgrant> It's left as an exercise for the reader.
[07:21] <wgrant> (you correctly translated a setting of innerHTML to setContent, which has the same escaping behaviour: none at all. And then user input is passed into that)
[07:22] <wallyworld> i thought i was fixing a xss by doing that ie that setContent did the escaping. i think i need setText then
[07:23] <wallyworld> i always get them mixed up
[07:23] <wgrant> Right, that would work.
[07:23] <wgrant> YOu also need to change the default name to '<name>' in that case.
[07:23] <wgrant> setContent is to be deprecated and replaced with setHTML, I believe.
[07:23] <wallyworld> i saw the xss and tried to fix it, but clearly didn;t quite get it right
[07:23] <wgrant> Because it's a hilariously deceptive name, as we see here.
[07:23] <wgrant> http://yuilibrary.com/projects/yui3/ticket/2531467
[07:23] <wgrant> So, set('text', foo)
[07:23] <wallyworld> yep
[07:24] <wgrant> Bug 911635
[07:25] <StevenK> I wonder if pycharm did that to him.
[07:29] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/calculateOldBinaries-use-denorm/+merge/88816 if you're still reviewing.
[07:30] <wgrant> StevenK: For that I would review any time :)
[07:30] <wgrant> Intriguing.
[07:31] <StevenK> wallyworld_: I didn't know pycharm had a "Kill Quassel" button.
[07:31] <wallyworld_> StevenK: it doesn't but precise does :-(
[07:31] <StevenK> wgrant: I'm still wondering if the if len(name_ids) test is even needed any more.
[07:32] <StevenK> wgrant: And which bit is?
[07:32] <wgrant> StevenK: The fact that wallyworld_ has a tail
[07:32] <wgrant> Despite the old one quitting before it.
[07:33] <wgrant> Oh, it only parted.
[07:35] <StevenK> wgrant: Removing the if len(name_ids) short circuit works, and drops the diff to +23/-32
[07:35] <wgrant> StevenK: The short-circuit is tiny optimisation, but still an optimisation.
[07:36] <wgrant> I don't know if it's still a major win, though.
[07:36] <wgrant> It's cheap to keep, so keep it for now.
[07:36]  * StevenK rewrites it to if not name_ids
[07:37] <StevenK> wallyworld_: What killed Quassel, anyway?
[07:37] <wgrant> No.
[07:37] <wallyworld_> StevenK: no idea. i closed and reopened it because it lost its network
[07:37] <wgrant> StevenK: implicit bool() on sequences when resultsets (which often lack a useful __nonzero__) are involved is a little worrying.
[07:38] <wgrant> StevenK: Why do you still join against BPN?
[07:38] <wgrant> For that matter, why was it joined against BPN in the first place/
[07:38] <wgrant> Oh
[07:38] <StevenK> Haha
[07:38] <wgrant> Because that's what it's actually getting.
[07:38] <StevenK> Right
[07:38] <wgrant> Carry on then.
[07:39] <StevenK> wgrant: The status = ( ... definition in the method made me go O.o
[07:39] <wgrant> Approvalised, anyvay.
[07:40] <wgrant> Now, you probably want to try this out somewhere like DF
[07:40] <wgrant> And work out what indices would help.
[07:41] <StevenK> Really?
[07:41] <wgrant> eg. possibly one on bpph(archive, distroarchseries, status, binarypackagename)
[07:41] <wgrant> Although it's probably not quite smart enough to know to use that.
[07:41] <StevenK> The indices on BPPH make me cry.
[07:45] <wallyworld_> wgrant: thanks for reviewing. i'll throw it as ec2 and hopefully by morning it will be throught bb also
[07:54] <wgrant> wallyworld_: No
[07:54] <wgrant> wallyworld_: lp-land
[07:54] <wallyworld_> wgrant: i changed code, so i want to send it via ec2 to be sure
[07:54] <wgrant> wallyworld_: This is unlikely to break tests, and even if it does break them we're no further behind.
[07:54]  * StevenK waits for postgres on mawson
[07:54] <wgrant> We cannot deploy until this is landed.
[07:54] <wallyworld_> ok. but if bb breaks....
[07:54] <wgrant> Then we still can't deploy until it's fixed.
[07:54] <wgrant> But the US people will know what the failures are.
[07:55] <wgrant> It's not dependent on you being awake and responsive.
[07:55] <wgrant> If buildbot doesn't break, we've saved 5 hours.
[07:55] <StevenK> wallyworld_: Given buildbot didn't fail this when mochi was killed makes me think it isn't tested.
[07:55] <wgrant> If it does break, we have to fix it before we can deploy either way.
[07:55] <wgrant> The only mitigating factor is that buildbot takes 1.5h longer than ec2
[07:55] <wallyworld_> ok
[07:55] <StevenK> Come ON, mawson
[07:56] <wgrant> StevenK: I probably murdered its caches.
[07:56] <StevenK> I want cold data anyway
[07:56] <wgrant> Not *that* cold.
[07:56] <StevenK> So I was going to SELECT * from BranchRevision for about 5 minutes before I switch queries.
[07:57] <wgrant> I just did a few full bug+bugsubscription reads and a few million writes to new tables.
[07:57] <wgrant> So there's probably not much cache left anyway.
[07:58] <wallyworld_> wgrant: can you lp-land it for me. bzr blew up just now when i tried with a AttributeError: 'BranchConfig' object has no attribute 'get' error
[07:58] <wgrant> wallyworld_: Awesome
[07:58] <wgrant> Sure
[07:58] <StevenK> How did you run it?
[07:58] <wallyworld_> thanks. url is https://code.launchpad.net/~wallyworld/launchpad/more-mochikit-fallout/+merge/88814
[07:58] <poolie> wallyworld_, that sounds like a plugin version mismatch
[07:58] <wallyworld_> bzr lp-land
[07:58] <poolie> depending on th tb
[07:59] <wallyworld_> poolie: only thing i've done today is delete a local installed xmloutput plugin so that the packaged one is used
[07:59] <poolie> please pastebin the traceback?
[08:00] <wallyworld_> poolie: https://pastebin.canonical.com/58207/
[08:00] <jelmer> wallyworld_: that seems like an outdated bzr-pqm plugin
[08:01] <wallyworld_> jelmer: i've never installed bzr-pqm manually, only via the packaged debs
[08:01] <poolie> jelmer, ah, passing the wrong config object in to smtpconnection?
[08:01] <wallyworld_> i upgraded to precise last friday
[08:01] <jelmer> poolie: yep
[08:01] <wallyworld_> it worked before then
[08:02] <jelmer> wallyworld_: ah, hmm
[08:02] <wallyworld_> sorry, just been called up for dinner. will check back a bit later
[08:05] <StevenK> wgrant: http://pastebin.ubuntu.com/807139/
[08:06] <StevenK> wgrant: New query with the same data is *massively* faster.
[08:06] <wgrant> Huh?
[08:06] <wgrant> 9s->4s is not massively faster :)
[08:06] <wgrant> It's still two orders of magnitude off what it should be.
[08:06] <StevenK> wgrant: 405783 / 112251 versus 16705 / 3792
[08:07] <StevenK> That could be because mawson is still cache starved.
[08:07] <wgrant> Erm
[08:07] <wgrant> Those plans are the same.
[08:08] <wgrant> One is hot.
[08:12] <StevenK> wgrant: Indeed. Editor fail
[08:14] <StevenK> wgrant: http://pastebin.ubuntu.com/807144/
[08:14] <wgrant> StevenK: That is slightly more like it :)
[08:15] <wgrant> Still terrible, but not OMGIWANTTODIE
[08:15] <StevenK> Haha
[08:15] <wgrant> What's the query?
[08:15] <wgrant> I shall hoptimise.
[08:16] <StevenK> wgrant: http://pastebin.ubuntu.com/807147/
[08:21] <wallyworld_> jelmer: anything i can do to help diagnose the problem?
[08:30] <wgrant> StevenK: 64ms
[08:31] <wgrant> Let's see if I can go lower.
[08:32] <jelmer> wallyworld_: I think I know what needs to happen
[08:32] <jelmer> wallyworld_: we'll need to upload a new bzr-pqm to unstable/precirse
[08:32] <wallyworld_> jelmer: ok. thanks :-)
[08:33] <wallyworld_> good to find this stuff early i guess
[08:34] <poolie> jelmer, i guess we could consider it a break in the smtp library and support the old interface
[08:34] <poolie> ie if isinstance etc
[08:34] <wgrant> StevenK:     "temp_binarypackagepublishinghistory" btree (archive, distroarchseries, status, binarypackagename)
[08:34] <wgrant> StevenK: And add a DISTINCT to the query
[08:34] <wgrant> 30-50ms on DF
[08:35] <wgrant> Which is still slightly high, but not bad.
[08:46] <StevenK> wgrant: .config(distinct=True) , right?
[08:47] <wgrant> StevenK: Correct.
[08:47] <StevenK> wgrant: I'll toss that at ec2. We can hit up stub for the index
[08:47] <wgrant> Yeah
[08:48] <tvoss> Good morning
[09:08] <mrevell> Hello devils
[09:09] <nigelb> Morning mrevell
[09:14] <jelmer> hello mr revell
[09:23] <adeuring> good morning
[10:30] <wgrant> lifeless: accesspolicyartifact.policy as an integer[] with intarray and gist == fast
[10:35] <lifeless> sweet
[10:35] <wgrant> (intarray's in contrib, though)
[10:35] <lifeless> I've been meaning to test tags as an array
[10:36] <lifeless> wgrant: contrib stuff is ok, we ran fti that way for a while
[10:36] <wgrant> I suspect it would be fast.
[10:36] <wgrant> But you'd need to intify them
[10:37] <lifeless> oh, gist only takes ints?
[10:37] <wgrant> intarray only takes ints
[10:37] <wgrant> You'd need a separate GiST implementation for strings.
[10:37] <lifeless> anyhow, night
[10:37] <wgrant> GIN would work better, but has the same issues as with fti
[10:37] <wgrant> Night!
[10:42] <StevenK> wgrant: I guess r14680 is untestable
[10:51] <wgrant> StevenK: Both taken care of.
[11:18] <allenap> wgrant: Do you know how I can land lp:~takluyver/lazr.uri/py3? I tried PQM and I tried just approving it (hoping there was a Tarmac somewhere), but without success.
[11:21] <wgrant> allenap: Hmm
[11:21] <wgrant> We can commit directly to it.
[11:21] <wgrant> But it looks like PQM was used at one point.
[11:24] <wgrant> [/home/pqm/archives/rocketfuel/lazr.uri/trunk]
[11:24] <wgrant> published_at=bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/lazr.uri/trunk
[11:24] <wgrant> PQM is still configured for it, but trunk has been moved...
[11:24] <wgrant> I'd just commit directly.
[11:27] <allenap> wgrant: Cool. Thank you :)
[11:33] <rick_h__> morning
[13:17] <lifeless> wgrant: http://www.pgsql.cz/index.php/PostgreSQL_SQL_Tricks#xpath_function_indexing
[14:51] <Laney> can somebody help me move https://code.launchpad.net/~laney/launchpad/spph-sponsor along?
[15:15] <jcsackett> sinzui: thanks for doing my qa, and sorry i forgot about it.
[15:15] <sinzui> Laney, Only lifeless can approve the branch for db-devel. I expect lifeless to be available in 5 hours
[15:16] <sinzui> jcsackett, np. I have a habit of checking the state of Lp when I wake up every day
[15:17] <sinzui> though today required hacks to lp's dev scripts because bzr has changed api in precise
[15:18] <jcsackett> fun times.
[15:23] <rick_h__> jcsackett: weren't you saying I needed to do to prep for review mentorship? Mail a list/check a box? I don't see anything in the wiki
[15:23] <jcsackett> rick_h__: i'm composing an email to you; it's actually not prep work.
[15:24] <jcsackett> just time slot, and then on thursday i'll walk you through reviewing over skype/mumble in the morning.
[15:24] <jcsackett> rick_h__: also, is this your preferred irc nick, or do you have trailing underscores today for nick collision reasons?
[15:24] <rick_h__> jcsackett: rick_h is the preferred, but yea I get trailing undercsores usually
[15:25] <rick_h__> I'm actually registered under an old name, but changed to rick_h for ease of figure out who I am
[15:29] <jcsackett> dig.
[15:29] <jcsackett> rick_h__: so, i'll be sending you an email and emailing the dev list to let people know you're on rotation just as soon as my mail client finishes grinding on some short-sighted batch email moves i told it to do. :-P
[15:30] <rick_h__> jcsackett: sounds like a plan, thanks
[15:30] <jcsackett> yw.
[15:43] <deryck> abentley, I'm actually starting on your review now. no applause please. ;)
[15:43] <abentley> deryck: :-)
[15:44] <deryck> abentley, also, I added a card for the branch.  I want to be a bit stricter about that over the next couple months, just for stats tracking curiosity on my part.
[15:44] <abentley> deryck: okay.
[15:56] <Laney> sinzui: hm? the docs say stub can do it too, and he has approved the proposal
[16:18] <sinzui> Laney, I see. Are you asking for someone to merge your branch? I think I can do that
[16:18] <Laney> sinzui: Yes I suppose so. I believe it also has to be QAed somehow before it is deployed too (ec2?).
[16:20] <sinzui> Laney, I will send it to ec2 and when all the tests pass it will be merged and run though buildbot. When all builders are successful, the staging.launchpad.net will be updated for qa
[16:21] <Laney> Sounds fun. Can I follow this process anywherE?
[16:23] <sinzui> well maybe I cannot. ec2 land does not want to work with precise and Lp
[16:23]  * sinzui tries test
[16:24] <Laney> heh
[16:24] <deryck> abentley, r=me.  looks great.
[16:24] <abentley> deryck: thanks.
[16:24] <deryck> abentley, np!
[16:30] <rick_h> bac: heads up, commercial request for canonical sizzle project coming your way from RT
[16:55] <cjwatson> Laney: The URLs I use to follow this are https://lpbuildbot.canonical.com/waterfall and http://lpqateam.canonical.com/qa-reports/deployment-stable.html.  I suspect you can see the latter but not the former.
[16:56] <Laney> correct
[16:56] <cjwatson> Laney: The buildbot isn't really terribly interesting though.  In practice you wait for a few hours for EC2 to finish, you get an e-mail saying the branch is merged, you wait for another eon or so for buildbot to finish, and a bit after it lands on qastaging the deployment report updates and a bot flips the bug status to Fix Committed and adds the qa-needstesting tag.
[16:57] <cjwatson> Laney: Once you get the bugmail for that last bit you can do QA.
[16:57] <Laney> ah, OK, it's all reflected in the merge proposal / bug
[16:58] <Laney> as it's a DB patch I guess it doesn't need QAing per-se
[16:58] <Laney> but after it's been applied to (qa)staging I can ask for the real branch to be reviewed or something
[16:59] <cjwatson> IIRC QA on a DB patch is mostly about whether it can apply fast enough hot, and maybe whether related views still work - https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess
[17:00] <cjwatson> You can ask for progress on the real branch once there's been a fastdowntime deployment with your DB patch
[17:00] <cjwatson> Which should show up by way of it disappearing from http://lpqateam.canonical.com/qa-reports/deployment-db-stable.html (note slight difference from previous URL)
[17:08] <Laney> great, thanks for the tips
[17:08] <Laney> Guess I'm waiting to for sinzui to figure out ec2 land :-)
[17:08] <sinzui> I started up an old computer and just updated it to run Lp
[17:08]  * Laney gets back to this paper review in the meantime
[17:08] <Laney> oh, rock
[17:09] <jcsackett> ...always fun to discover you've been disconnected from irc for who knows how long ...
[19:23] <lifeless> flacoste: I'm around $whenever though from +30 to +50 I'll be out getting meds for cynthia
[19:44] <flacoste> lifeless: ok, ping me when you are back
[20:00] <mwhudson> jelmer: _now_ i have a mail from you about feature flags :)
[20:01] <jelmer> \o/
[20:01] <jelmer> I wonder what void it has been spending its time in.
[20:01] <mwhudson> jelmer: "ganieda.lan" apparently
[20:02] <jelmer> *confused*
[20:02] <jelmer> that's the hostname of my old laptop
[20:02] <mwhudson> jelmer: haha
[20:03] <mwhudson> jelmer: http://paste.ubuntu.com/807804/
[20:04] <jelmer> hmm
[20:04] <Ursinha> what does this mean when trying to start a local launchpad instance? "Exception: Timeout waiting for RabbitMQ server to start."
[20:04] <Ursinha> except the obvious :P
[20:05] <mwhudson> it's possible postfix still thinks it's hostname is ganieda if you just transplanted /etc? :)
[20:12] <jelmer> mwhudson: yeah, that appears to be the case (not sure why, I think I did a clean install)
[20:12] <jelmer> mwhudson: either way, glad it finally surfaced. I'm still planning to have a look at using those feature flags in the codehosting ssh server some time.
[20:13] <jelmer> Ursinha: I remember seeing that at some point, but I don't recall what the cause was I'm afraid..
[20:19] <mwhudson> jelmer: cool
[20:19] <flacoste> lifeless: back yet?
[20:19] <mwhudson> jelmer: i guess you don't actually need a reply to the mail :)
[20:20] <jelmer> mwhudson: nope, thanks
[21:19] <flacoste> lifeless: on the phone with gary
[21:19] <lifeless> flacoste: kk
[21:20] <lifeless> Ursinha: it means the obvious; did you get a trace with a log file or anything like that ?
[21:45] <flacoste> lifeless: call back
[22:11] <StevenK> sinzui: http://pastebin.ubuntu.com/807933/
[22:59] <StevenK> wallyworld: Let me know how you go with convoy, by the by
[23:46] <wgrant> lifeless: I'd like your thoughts on https://code.launchpad.net/~wgrant/launchpad/hardcoded-password/+merge/88966
[23:49] <sinzui> StevenK, you are a launchbag victim
[23:49] <sinzui> add this to your test after you create the bug
[23:49] <sinzui> getUtility(ILaunchBag).add(bug.default_bugtask)
[23:49] <StevenK> RARGH, LaunchBag
[23:50] <sinzui> StevenK, maybe you need to get angry and take a knife to all uses of launchbag in browser.bugtask
[23:50] <sinzui> I cannot think of a legitimate reason that the context object does not provide what we want
[23:50] <StevenK> sinzui: I have considered that option, but I'm not sure 1) What browser.bugtask is using ILaunchBag for, and 2) What the fallout would be
[23:51] <sinzui> StevenK, how many hours has this team spent debugging launchbag. I think we can take a few to replace anything that uses it with the object in scope, then send the branch to ec2.
[23:52] <sinzui> If you accidentally pass the -s switch and with [r=sinzui][no-qa] you might get a pleasant surprise
[23:52]  * sinzui looks at code
[23:52] <StevenK> sinzui: You'd like me to kill ILaunchBag entirely, or just where it hit me?
[23:54] <StevenK> OH DAMN IT
[23:54]  * StevenK resigns his .changes with his old key and uploads it to DF
[23:56] <sinzui> StevenK, I think it is worth an hour to replace as must as possible...
[23:56] <sinzui> 1. LaunchpadView.user == bag user
[23:58] <sinzui> 2. if the context is a bug, the use the bug.default_bugtask
[23:59] <sinzui> Oh, and you may need to pass the user as the principal when if the test added the user to the bag