[00:00] <bryceh> :-)
[00:00] <nigelb> Its beautiful!
[00:00] <nigelb> Also, there is this space "&commit= Send Upstream"
[00:01] <nigelb> it should not exist I think, so the commit button would change to Send upstream?
[00:01] <nigelb> ok, tested.  No.
[00:02] <nigelb> Anyway its the most awesome thing I've seen.  If LP does this by default, we'd all hug you :)
[00:02] <bryceh> I think that's fine, that value isn't actually used by bugzilla
[00:02] <nigelb> Yeah, I just noticed
[00:04] <bryceh> well, it may be a while before LP does this by default, but I'll be working on it.  meanwhile the cgi is going to be available for folks
[00:04] <bryceh> I'll be interested in seeing how much use it gets
[00:06] <bryceh> I'd also be interested in hearing about tangible time savings.  I calculated after spending one day forwarding bugs without this tool, vs. one day forwarding bugs with it, I was able to send 3 times as many bugs upstream in a given period of time
[00:07] <bryceh> the main constraint for me in achieving an even better ratio was having to manually copy over the attachments
[00:09] <bryceh> nigelb, thanks for finding that bug.  embarrassing!
[00:09] <bryceh> clearly I need to write some tests
[00:10] <nigelb> heh
[00:10] <nigelb> another advantage when you have a tool like this, people don't go, "Oh, I'll forward it later"
[00:10] <bryceh> nigelb, did you install the greasemonkey script?
[00:10] <nigelb> they'll just.  "hey, it'll take only 10 minutes, why not do it"
[00:10] <bryceh> yep
[00:11] <nigelb> Nope, I did it manually.
[00:11] <nigelb> (this is work computer, can't mess with it :D)
[00:12] <bryceh> mm, if/when you can install that gm script, you'll find it REALLY makes it fun and easy to upstream bugs
[00:12] <nigelb> Oh!
[00:14] <nigelb> how tough would it be to make it available for gnome bugzilla too?
[00:14] <bryceh> it should work with gnome bugzilla already
[00:14] <bryceh> I only tested on a couple bugs though so am not 100% sure
[00:14] <nigelb> gnome has more people forwarding since the apps are mostly in user space
[00:14] <bryceh> but I put the support for GNOME in last week.  I'd love to get verification that it works
[00:14] <bryceh> yep
[00:15] <bryceh> it should work for gnome packages that have exactly the same name in launchpad and in gnome bugzilla
[00:16] <bryceh> which afaik should cover most packages
[00:16] <nigelb> where in the lp branch is the code?
[00:16] <bryceh> it's in the scripts directory
[00:18] <nigelb> its a very nifty script :)
[00:19] <bryceh> thanks, yeah I've gotten a lot of good out of it, and looking forward to it being handy for others
[00:19] <bryceh> nigelb, let me know if you test it on a gnome bug
[00:22] <nigelb> I will as soon as I can find the time.  gotta start working :)
[00:22] <bryceh> nigelb, cheers :-)
[03:18] <Ursinha> lifeless, missed your request -- "partial" oops summaries, as we call, are regenerated every hour
[04:26] <lifeless> Ursinha-afk: thanks
[04:41] <lifeless> spm: can you time the statement in https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1662O772 ? - the 17 second one, on a slave, and on prod, please?
[04:41] <spm> sure
[04:42] <lifeless> if its slow, grab an explain analyze too :)
[04:42] <spm> wow. that's... inconsistent.
[04:43] <spm> enter query into cmd line; hit enter; runs, completes. uparrow+enter; repeat.
[04:43] <lifeless> .
[04:43] <lifeless> .
[04:43] <lifeless> .
[04:43] <spm> 1.7s, 13.1s, 0.6s, 1.0
[04:44] <lifeless> we might want to fix this
[04:44] <spm> wtf (where) did  13.1 come from!!!
[04:44] <lifeless> was that on a slave or main ?
[04:44] <spm> main
[04:45] <spm> what makes that 13.1s even more interesting, i'd have thought the query was still within postgres caching. ie it should be zomg fast.
[04:45] <lifeless> so
[04:45] <lifeless> guesses: load, index fail, index lock contention
[04:45] <spm> cache fail...
[04:45] <lifeless> if we're under that much pressure, sure.
[04:46] <lifeless> we're seeing the oops 180 times a week
[04:46] <spm> load, unlikely - load average: 8.31, 7.91, 8.14 <== which is pretty low for wildc
[04:46]  * lifeless mutters about perspective
[04:46] <spm> note the 'unlikely' qualifier. :-)
[04:47] <lifeless> how many cores does it have?
[04:47] <spm> when you'd had dual 650Mhz CPU proxy firewalls on a 'normal' load of 50-80; still working at 450...
[04:47] <spm> 16
[04:48] <lifeless> ok, so thats still 8 db threads or similar not executing for a full second
[04:48] <lifeless> its not actually great
[04:48] <lifeless> later we will have to go into the performance knee for wildc
[04:49] <lifeless> right now, we already know that backsup cause an oops spike :P
[04:49] <spm> ? I thought load was a (rough) measure at the end of a 'tick' of what's executing right now; regardless of how much of the tick they've had? imbw....
[04:49] <spm> ie it avergaes out to a vague approximation.
[04:49] <lifeless> its blocked ready-to-run processes
[04:50] <lifeless> http://blog.scoutapp.com/articles/2009/07/31/understanding-load-averages - not telling you to suck eggs, but I've quickly scanned it and its a clear explanation
[04:50] <spm> heh, I suspect we're using different words to describe the same thing. :-)
[04:50] <spm> ta
[04:52] <lifeless> ok anyhow
[04:52] <lifeless> one thread at a time
[04:52] <spm> :-)
[04:52] <lifeless> can you see if it does that slow pattern on a slave
[04:54] <spm> huh, I was almost going to say o it doesn't, but persistence paid off. most (~ 10 runs ish) were sub 0.3s, 1 x 1.0, 1x 4.5.
[04:54] <spm> s/ o / no /
[04:54] <lifeless> ok
[04:54] <spm> 8 cores, load average: 1.01, 1.18, 1.15
[04:54] <lifeless> can you get an explain analyse of it slow in both cases ?
[04:55] <spm> Oooer. it changed!
[04:57] <spm> wow. I didn't notice. it changed twice. https://pastebin.canonical.com/34873/
[04:57] <spm> actually... i think it was different on every run. repasting the entire test
[04:58] <spm> https://pastebin.canonical.com/34874/
[04:58] <lifeless> *boom*
[05:00] <spm> yeah. something is *really* screwy, based on my DB understandings if the explain plan can be changed so dramatically like that. I thought these things were cached for high seconds to low minutes for precisely this sort of thing.
[05:00] <spm> https://pastebin.canonical.com/34875/ to complete the set, wildcherry showed similar behaviour
[05:01] <lifeless> ah
[05:01] <spm> actually I quite distinctly do recall faffing around with Oracle... 10g istr and forcibly getting it to regen plans 'offline' as it were to maximise the speed of certain queries
[05:02] <lifeless> its a damned view
[05:02] <lifeless> omfg
[05:02] <lifeless> excuse me
[05:02] <spm> no perfectly understandable :-)
[05:02] <lifeless> \d publishedpackage :P
[05:02] <spm> It is pretty unthinkable that'd I've used oracle and actually like it. ;-)
[05:03]  * spm takes a few deep breaths
[05:04] <wgrant> Oh god, publishedpackage?
[05:04] <wgrant> Kill it.
[05:04] <spm> oh not too bad. only 12 joins.
[05:04] <wgrant> The *cache table* is being slow?
[05:04] <lifeless> in the fast one is its a nested loop
[05:04] <lifeless> pg doesn't hve materialized views does it?
[05:04] <spm> unknown to me
[05:04] <lifeless> don't think so
[05:05] <wgrant> You can emulate them using triggers, but it doesn't do them itself, no
[05:05] <lifeless> so the fast case loops on binarypackagename_name_key on binarypackagename
[05:06] <lifeless> the slow case Seq Scan on buildfarmjob  (cost=0.00..54641.45 rows=1799245 width=12) (actual time=0.019..1470.653 rows=1799572 loops=1)
[05:06] <lifeless> and it gets worse from there
[05:06] <wgrant> That table has only been around for a couple of months.
[05:06] <wgrant> So the query probably hasn't been looked at in this form before.
[05:07] <lifeless> I need to review this, I smell OOD rather than table layout optimisation
[05:07] <lifeless> I saw a similar thing last night
[05:08] <lifeless> spm: so I'm guessing slight statistics variation -> boom
[05:09] <spm> lifeless: I guess, but... I'm kinda left wondering why plans aren't locked in stone more; if they even can be.
[05:11] <lifeless> spm: do I have sql access to staging, to poke at the tables a bit ?
[05:11] <spm> perhaps comparing oranges with mandarin's; in oracle land - as I recall it; you'd have a generic query plan with placeholders for the values. there's a specific name, but time and memory fades. the idea being that you just replace the bits you care about; the plan itself is indentical; so you win big on lots of repititions by not doing the analyze phase(s)
[05:11] <spm> lifeless: perhaps r/o? if not, I can create now and retroactively ask francis for you to have same.
[05:12] <lifeless> spm: whatever bjorn had?
[05:12] <spm> I have 99.99999% no doubt he'll be fine with that.
[05:12] <spm> everyone except losas and stub has r/o
[05:12] <lifeless> I'm sure that will be fine
[05:12] <spm> rephrase, everyone *with access* has r/o
[05:12] <lifeless> if its ever not, well, efuture
[05:44] <lifeless> wgrant: so why do you say to delete hte view?
[05:45] <wgrant> lifeless: I was wrong. I was thinking it was one of the cache tables.
[05:46] <wgrant> But it's not; it's just a view.
[05:53] <lifeless> 10 million rows in bpph
[05:53] <lifeless> I can has delete?
[05:53] <wgrant> You can has indices.
[05:53] <lifeless> meh
[05:53] <lifeless> I has indices.
[05:53] <lifeless> I wants delete.
[05:54] <lifeless> also fti needs some serious love
[05:54] <wgrant> Deleting history makes me sad.
[05:54] <wgrant> What's the FTI on?
[05:55] <lifeless> wgrant: keeping stuff isn't free
[05:55] <lifeless> and even logn perf hurts after a while
[05:55] <wgrant> lifeless: Says he who developed a DVCS which preserves all history :P
[05:55] <lifeless> its all about use cases
[05:56] <lifeless> actually, I want a good history edit mechanism - I wrote that up a year back or so
[06:00]  * wgrant still needs someone to land a branch.
[06:19] <lifeless> spm: are you able to do iostat/cpu on staging for a query for me?
[06:20] <lifeless> wgrant: whats the mp
[06:22] <wgrant> lifeless: One of the ones you reviewed a couple of days ago.
[06:22]  * wgrant hunts.
[06:22] <wgrant> https://code.edge.launchpad.net/~wgrant/launchpad/refactor-_dominateBinary/+merge/29667
[06:22] <lifeless> oh, I might need a newer tree
[06:22] <lifeless> we'll see
[06:23] <mwhudson> herh
[06:23] <mwhudson> lp.registry.windmill.tests.test_person_picker.TesPersonPickerWidget.test_person_picker_widget is failing in my branch
[06:24] <mwhudson> nice test class name!
[06:26] <lifeless> wgrant: its mid kickoff
[06:26] <wgrant> lifeless: Thanks.
[06:26] <lifeless> losa ping
[06:35] <mwhudson> how do you debug a failing windmill test?
[06:35] <lifeless> WITH A SHOTGUN
[06:39] <lifeless> wgrant: its in flight
[06:39] <wgrant> lifeless: Even better.
[06:40] <wgrant> It *is* the right branch?
[06:40] <wgrant> Last night it wasn't.
[06:40] <lifeless> i just cp'd your link
[06:41] <mwhudson> lifeless: it seems "run it until it passes" works :(
[06:42] <wgrant> mwhudson: My policy is "run until it passes. if it still doesn't pass, ignore it, because I didn't break it"
[06:47] <spm> lifeless: sure, on staging DB server as in?
[06:52] <lifeless> yes
[06:53] <lifeless> the qyry is
[06:53] <lifeless> \timing
[06:53] <lifeless> SELECT COUNT(CASE WHEN Bug.fti @@ ftq('sphinx') THEN TRUE ELSE null END) FROM Bug, BugTask WHERE BugTask.bug = Bug.id AND BugTask.distribution = 1;
[06:56] <spm> lifeless: I forgot to time() it; but ~ 10ish seconds. https://pastebin.canonical.com/34879/ for the vmstat
[06:57] <lifeless> \timing is your friend :)
[06:57] <spm> aye... :-/
[06:58] <spm> 2nd run - just shy of 9 secs
[07:00] <lifeless> ok
[07:00] <lifeless> a fucktonne of IO
[07:00] <lifeless> spm: can you check whether lucene, solr & pylucene are available in the DC, in the event we were to want to use them.
[07:01] <spm> are they debug type programs? servers?
[07:01] <spm> ah the first is the search engine?
[07:03] <lifeless> yes
[07:03] <lifeless> one stack
[07:03] <spm> lifeless: looks like, not really. some possibly defaultish libraries; but I'd suggest backporting would be needed.
[07:04] <lifeless> rmadison was hopefyul
[07:07] <mwhudson> i know the divmod folks became extremely angry with lucene
[07:07] <mwhudson> several years ago now, mind
[07:11] <lifeless> spm: it appears to be in universe, to me
[07:13] <spm> lifeless: that would be my lack of experience with dealing with packages then
[07:13] <lifeless> hahahha
[07:13] <spm> or possibly we don't enable universe on the servers...
[07:13] <lifeless> spm: whats our policy on stuff in univers
[07:13] <lifeless> e
[07:14] <spm> actually I can see the solr stuff, I sit corrected.
[07:14] <spm> heh, lalala me. universe is fine.
[07:15] <lifeless> spm: how hard am I hammering the server ?
[07:16] <spm> 100% on one cpu only
[07:16] <lifeless> \o/
[07:16] <lifeless> select * from stat('select fti from Bug') order by ndoc desc, nentry desc,word limit 10;
[07:16] <lifeless> how many cpus are there ?
[07:16] <spm> 8 cores
[07:17] <spm> only 32g of ram, so i'd expect more io than prod
[07:17] <spm> whee that local run is evil you've made me do. also 100%
[07:18] <spm> 0.0% wait state tho
[07:39] <lifeless> spm: I'd like to try reindexing bug.fti on staging.
[07:39] <lifeless> spm: how do we go about this?
[07:40] <spm> depends on how intrusive a reindex you mean? if you just mean 'reindex table blah', that's pretty easy.
[07:40] <lifeless> spm: or should I do that on dogfood
[07:40] <lifeless> spm: we need to drop the bug_fti index and make a new gin one
[07:40] <lifeless> something like
[07:40] <spm> I'd suggest dogfood in the first instance to get an idea of timing
[07:40] <mwhudson> lifeless: when did test_suite() stop being necessary in launchpad tests?
[07:40] <mwhudson> (also yay!)
[07:41] <lifeless> mwhudson: I don't know, but jtv tested and current zope.testing doesn't seem to need it.
[07:41] <spm> lifeless: it'd also be my personal recommendation to run any reindexing past stub
[07:41] <lifeless> spm: how do I get access to dogfood ?
[07:41] <mwhudson> maybe zope.testing grew a new feature then
[07:41] <spm> lifeless: if you don't have already? via RT
[07:41] <lifeless> spm: I've spoken to stub about the fti stuff; its  basically untuned - he expressed frustration at not having had time to just sit down and zen it
[07:42] <spm> heh
[07:42] <lifeless> mwhudson: hell, it may be needed still - remove it and check :)
[07:42] <mwhudson> lifeless: i did
[07:42]  * spm can picture stub doing the OOOOOmmmmm thing before a DB layout diagram
[07:43] <wgrant> spm: dogfood is *completely* useless for timing.
[07:43] <wgrant> You know what sort of hardware it's on, right?
[07:44] <lifeless> so the thing is
[07:44] <lifeless> we have a fast-insert slow-query fti index
[07:44] <spm> wgrant: I'm think of more an 'minutes vs hours vs days' idea
[07:44] <lifeless> there is an alternative index
[07:44] <spm> not 17.65 minutes.
[07:44] <lifeless> the gin index
[07:44] <wgrant> spm: dogfood cannot always give a reasonable answer over those three.
[07:44] <lifeless> anyhow this isn't urgent
[07:44] <spm> haha
[07:44] <lifeless> I'm just starting to qualify simple-complex answers in this space
[07:44] <wgrant> Recall that a DB restore took two weeks a few months ago.
[07:45] <wgrant> And the primary publisher takes several hours.
[07:45] <mwhudson> lifeless: this talk of gin indexes rings faint bells, i think we already use them for something...
[07:45] <mwhudson> or tried
[07:46] <mwhudson> still if you talked to stub you're likely much more up to date than me :)
[08:01] <lifeless> mwhudson: yes :)
[08:11] <wgrant> lifeless: Are Forbbiddens logged?
[08:11] <wgrant>  /builders is 403ing sometimes.
[08:11] <lifeless> should be
[08:11] <lifeless> I don't know if they raise oopses
[08:12] <mwhudson> they aren't logged as oopses when you're logged in, i think
[08:12] <wgrant> mwhudson: So we can't debug them?
[08:13] <wgrant> Awesome.
[08:13] <lifeless> wgrant: thats not entirely true
[08:13] <mwhudson> wgrant: i may have been lying there
[08:13] <poolie> lifeless, jam and i looked at the memcached graphs last night
[08:13] <mwhudson> wgrant: i think bigjools knows the problem though
[08:13] <poolie> as i suppoe you already have before
[08:13] <mwhudson> wgrant: it's private builds, unsurprisingly
[08:13] <poolie> they seem clearly size-limited
[08:13] <wgrant> mwhudson: He suspects private teams.
[08:13] <lifeless> wgrant: however, I encourage you, in the theme of improvign things, to add trace logs for this
[08:13] <poolie> and hitting only about 20% of the time
[08:14] <lifeless> yeah
[08:14] <wgrant> mwhudson: But I can't see any private builds, so I shouldn't see any private teams.
[08:14] <lifeless> I don't really have memcache on my radar atm
[08:14] <poolie> so caching more things is likely to make the cache perform worse :)
[08:14] <lifeless> its a tool we're not ready for
[08:14] <wgrant> It's already overused.
[08:14] <wgrant> Caching things that should not be cached.
[08:14] <poolie> i know
[08:14] <lifeless> lpmain_staging=> SELECT COUNT(CASE WHEN Bug.fti @@ ftq('sphinx') THEN TRUE ELSE null END) FROM Bug, BugTask WHERE BugTask.bug = Bug.id AND BugTask.distribution = 1;
[08:14] <lifeless>  count
[08:14] <poolie> i was thinking of letting it be refreshed from the browser by cache-control
[08:14] <lifeless> -------
[08:14] <lifeless>     40
[08:14] <lifeless> (1 row)
[08:14] <lifeless> Time: 7659.528 ms
[08:15] <lifeless> lpmain_staging=> SELECT COUNT(*) from Bug, bugtask  where bug.fti @@ ftq('sphinx') and BugTask.bug = Bug.id AND BugTask.distribution = 1;
[08:15] <lifeless>  count
[08:15] <poolie> i now feel we should add a switch to jut turn it off, and see if the oops rate changes
[08:15] <lifeless> -------
[08:15] <lifeless>     40
[08:15] <lifeless> (1 row)
[08:15] <lifeless> Time: 526.478 ms
[08:15] <lifeless> we can just turn it off
[08:15] <lifeless> and no, not pastbinning that :P
[08:15] <lifeless> *thats* easy
[08:15] <wgrant> poolie: There is lots of stuff that should be cached.
[08:15] <wgrant> poolie: But it's not the stuff that's cached at the moment.
[08:16] <mwhudson> lifeless: those times are, um, different
[08:16] <wgrant> lifeless: What's the difference in the plan?
[08:16] <poolie> lifeless, so tbf there are a lot of cache effects on the db server
[08:16] <lifeless> wgrant: give you a single guess
[08:16] <poolie> running two queries one after the other and seeing the second is faster does not necessarily prove anything
[08:17] <poolie> (in my limited experience)
[08:17] <poolie> i agree the second looks more sensible
[08:17] <lifeless> of course
[08:17] <lifeless> I've run 10 of each
[08:17] <spm> running 4 and having the 4th run an order of magnitude slower tho....
[08:17] <lifeless> but thats a lot more noisy ;)
[08:17]  * mwhudson gets some 503s and 504s from the apache frontend :(
[08:17] <poolie> ah :) and it's consistent? fairy nuf
[08:17] <lifeless> sometimes the slow one is worse
[08:18] <spm> https://pastebin.canonical.com/34874/ <== for mindblowing enjoyment
[08:18] <lifeless> ok, so edge deployment just failed to migrate smoothly ?
[08:18] <lifeless> mwhudson: please file a bug
[08:18] <mwhudson> it's working now
[08:18] <spm> edge was just updating
[08:18] <lifeless> yes
[08:18] <mwhudson> ah
[08:18] <lifeless> this is a bug
[08:18] <lifeless> we should fix it, we're going to be doing this *much* more often
[08:19] <lifeless> mwhudson: please file it ;)
[08:19] <mwhudson> lifeless: ok
[08:19]  * mwhudson waits to see if the bug search times out...
[08:20] <spm> short of automatically adjusting the 'load balancing' away from each server and waiting for all existing connections to same to timeout, there will be glitches for some folks?
[08:20] <lifeless> spm: thats exactly what we should be doing
[08:20] <wgrant> Hm. Is there no way to see all of a project's branches?
[08:20] <lifeless> code.lp.net/project
[08:20] <wgrant> No.
[08:21] <wgrant> It's batched.
[08:21] <wgrant> But without a navigator.
[08:21] <wgrant> So it only shows the first n.
[08:21] <mwhudson> lifeless: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/608065
[08:21] <_mup_> Bug #608065: get occasional 503s and 504s from apache frontend when edge is updating <rollout-reliability> <Launchpad Foundations:New> <https://launchpad.net/bugs/608065>
[08:21] <lifeless> _huh_
[08:21] <wgrant> Ah!
[08:21] <wgrant> +branches is batched and has a navigator.
[08:21] <wgrant> But isn't linked from anywhere.
[08:21] <lifeless> ouch
[08:22] <wgrant> mwhudson: Do you know why this is so?
[08:22]  * mwhudson afks
[08:22] <mwhudson> wgrant: no
[08:22] <poolie> wgrant, use an api
[08:22] <poolie> :/
[08:23] <wgrant> poolie: There's UI. It's just got no links to it.
[08:23] <lifeless> wgrant: you may find https://bugs.edge.launchpad.net/malone/+bug/607776 interesting
[08:23] <_mup_> Bug #607776: +filebug-show-similar FTI query timeouts <oops> <timeout> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/607776>
[08:23] <poolie> then how does it smell? :)
[08:24] <wgrant> 'Seq Scan on bugtask'
[08:24] <wgrant> WTF
[08:24] <lifeless> yes
[08:24] <lifeless> case statement fail
[08:25] <poolie> lifeless, why would you even write such a query?
[08:25] <lifeless> ORM
[08:25] <lifeless> or confusion
[08:25] <poolie> is there some innocuous stortm thing that produces it?
[08:25] <lifeless> I don't know; the question is how long it will take to find and fix them all
[08:25]  * poolie wonders if storm should sometimes generate Warnings
[08:26] <wgrant> lifeless: Well, if we take the timeout down to 1s, they should all become fairly clear :P
[08:26] <lifeless> wgrant: I want to get the timeout to 5s
[08:26] <wgrant> I really love that you are actually concerned about speed, BTW.
[08:26] <lifeless> 1 would be ok if we generally completed in 0.1s
[08:26] <wgrant> It is something that has been missing from LP for... well... 5 years now.
[08:27] <lifeless> mmm
[08:27] <lifeless> All I'm offering is a detailed view
[08:27] <poolie> istm storm could also warn about 1=2
[08:27] <poolie> not sure if it's worth it
[08:27] <lifeless> the whole team has cared and been fixing stuff
[08:27] <lifeless> its important not to forget that
[08:28] <poolie> yeah it's really inspiring how much the atmosphere was different last week to previously
[08:28] <wgrant> True.
[08:28] <lifeless> if I am lucky enough to have some experience solving performance issues and dealing with interlocking pessimisations - its because I've created my fair share!
[08:28] <wgrant> Haha.
[08:30] <spm> damn. that's an admission and a half. /me takes a copy for later blackmail potential ;-)
[08:31] <wgrant> lifeless: Are you doing DB reviews now in Björn's place?
[08:31] <lifeless> yes
[08:32] <lifeless> two votes, stub & I
[08:32] <lifeless> we've agreed that with one vote it can progress to the tree
[08:32] <lifeless> two votes for deployment
[08:32] <wgrant> Ah, handy.
[08:36] <wgrant> rockstar: Hm, what's particularly difficult about fixing the factory? I saw it broke quite a few tests (which was why i didn't fix it then and there), but nothing that looked terribly hard to fix.
[08:36] <lifeless> mwhudson: I'm not going to get to your review - sorry, I'd love to:) - I'll try to drop a couple of thoughts in it today though.
[08:36] <rockstar> wgrant, most of our tests are wrong...
[08:37] <wgrant> Hah.
[08:37] <wgrant> Awesome.
[08:37] <rockstar> wgrant, so the tests that aren't breaking are the worst.
[08:37] <rockstar> wgrant, it's not "hard" per ce, just tedious, and probably not the best use of my time currently.
[08:37] <wgrant> Yep.
[08:39] <rockstar> wgrant, there are all sorts of hidden constraints inside soyuz that aren't really documented that I didn't know, and that we're not really exercising in tests anywhere.
[08:40] <wgrant> rockstar: lalala not part of Soyuz any more lalala
[08:40] <lifeless> wgrant: you're not?
[08:40] <wgrant> lifeless: The code isn't.
[08:40] <lifeless> soyuz.add(wgrant)
[08:40] <lifeless> :P
[08:40] <wgrant> lp.buildmaster's owned by everyone now :P
[08:40] <rockstar> wgrant, for instance, the build farm gets DOSed if you submit a build that isn't against a distroseries that isn't part of the ubuntu distro.
[08:40] <lifeless> wgrant: all code is owned by everyone anyway, in principle.
[08:41] <lifeless> I'd like to see more application of that principle :)
[08:41] <wgrant> rockstar: Hm, because they have no chroots?
[08:41] <wgrant> Or is there something else?
[08:41] <lifeless> bad error handling logic
[08:41] <lifeless> AIUI
[08:42] <mwhudson> lifeless: fairy nuff
[08:42] <wgrant> Well, of course, it's ex-Soyuz code.
[08:42] <rockstar> lifeless, probably a little bit of everything.
[08:43] <lifeless> whats the easiest way to join the dots from a page id to code
[08:43] <wgrant> I guess which app it's likely to reside in, then grep the app's browser/configure.zcml.
[08:43] <rockstar> lifeless, this is another question I had when I first started working on Launchpad that would have been immensely helpful in my ramp up.
[08:43] <wgrant> There must be a better way.
[08:44] <lifeless> why does Distribution:+filebug need to know SELECT COUNT(*) FROM Bug, BugTask WHERE BugTask.bug = Bug.id AND BugTask.distribution = 1 AND (1=1) ?
[08:51] <lifeless> so next ramp up question
[08:52] <lifeless> lib/lp/bugs/templates/bugtarget-filebug-search.pt calls into +filebug with id filebug-search-form
[08:52] <lifeless> what maps that back to a new template / api call ?
[08:52] <lifeless> grep only finds a js file
[08:52] <wgrant> The dupefinder is JS.
[08:53] <lifeless> ok
[08:53] <lifeless> so its setting up a call into a js function
[08:53] <rockstar> lifeless, yes.
[08:53] <lifeless> which then calls an api to do the deed
[08:54] <rockstar> lifeless, we use the term "api" very liberally, but yes.
[08:54] <lifeless> it makes a call to something that isn't formatted in tal :)
[08:54] <rockstar> lifeless, yes.
[08:54] <rockstar> REST api, model api...
[08:54] <lifeless> ok, its a self post
[08:55] <lifeless> to the same template with a query
[08:55] <lifeless> now... what maps *that* is my next connector to join
[08:57] <wgrant> lifeless: Must be in FileBugGuidedView somewhere. I suspect it's inherited from FilebugShowSimilarBugsView.
[08:58] <wgrant> (yay, consistent capitalisation...)
[08:58] <wgrant> What's the query?
[09:08] <lifeless> wgrant: hmm?
[09:08] <lifeless> wgrant: sorry, I've clearly confused you
[09:08] <lifeless> I'm working on the filebug timeouts
[09:08] <lifeless> we're using fti inefficiently
[09:09] <lifeless> I've spawned enough bugs to keep everyone busy for a few days, time to pitch in and help
[09:09] <lifeless> also
[09:09] <lifeless> volunteer needed to do a i18n patch for lp
[09:10] <wgrant> lifeless: lib/lp/bugs/model/bugtask.py, findSimilar
[09:10] <wgrant> (not findSimilarBugs)
[09:10] <wgrant> Hm.
[09:10] <wgrant> Hasn't i18n been rejected a few times?
[09:10] <lifeless> wgrant: so dots do you join to get to that
[09:10] <wgrant> I thought it was very much unwanted.
[09:10] <lifeless> wgrant: I thought it was 'too hard'
[09:10] <lifeless> wgrant: We have massive i18n in answers
[09:10] <rockstar> ETOOMANYTASKSTOOLITTLEDEVELOPERS
[09:11] <wgrant> lifeless: Uh, well, I looked at FileBugGuidedView, and saw that it didn't have that functionality. But there's a very suspicious base class: FilebugShowSimilarBugsView
[09:11] <wgrant> That calls findSimilar.
[09:11] <wgrant> lifeless: So: guesswork.
[09:11] <lifeless> what took you to FileBugGuidedView ?
[09:12] <lifeless> wgrant: and whats calling into findSimilar
[09:12] <lifeless> there are other nuts queries involved
[09:12] <rockstar> lifeless, I'm happy to show you how I connect the dots.
[09:12] <wgrant> lifeless: FilebugShowSimilarBugsView calls findSimilar.
[09:13] <rockstar> But also, there's ++oops++ to see some of the callins.
[09:13] <wgrant> I found FileBugGuidedView by checking lib/lp/bugs/browser/configure.zcml
[09:13] <lifeless> ok
[09:13] <lifeless> I think thats about my new-info buffer for now
[09:17] <lifeless> wgrant: did you have a db patch ?
[09:17] <wgrant> lifeless: Yeah. But the MP doesn't have a description quite yet.
[09:17]  * wgrant is just cleaning it up.
[09:28] <rockstar> wgrant, do you know how to get the tests to tell me all the queries a test is running?
[09:28] <wgrant> rockstar: I just use the postgres log.
[09:35] <wgrant> lifeless: Review requested.
[09:37] <lifeless> url me up
[09:37] <wgrant> lifeless: https://code.edge.launchpad.net/~wgrant/launchpad/link-uploaded-ddebs/+merge/29669
[09:40] <lifeless> what does binarypackagerelease represent
[09:41] <wgrant> A Debian binary package.
[09:41] <wgrant> ie. a .deb
[09:41] <wgrant> Or a .udeb
[09:41] <wgrant> Or now a .ddeb
[09:41] <lifeless> man, we have terrible names
[09:41] <wgrant> You just noticed?
[09:41] <wgrant> Would you like a DistroArchSeriesBinaryPackageRelease, which is of course short for DistributionArchitectureSeriesBinaryPackageRelease?
[09:41] <wgrant> We have one of those.
[09:42] <rockstar> lifeless, those clever landscape devs already wrote a tool to do what we were talking about.
[09:42] <lifeless> \o/
[09:43] <lifeless> is it open sourced yet ?
[09:44] <lifeless> wgrant: oh, I know. I was just compelled to comment
[09:44] <lifeless> its like a class called IntegerInstance
[09:44] <rockstar> lifeless, https://pastebin.canonical.com/34889/
[09:44] <lifeless> jml just deleted something along those lines
[09:45] <lifeless> check annotate of our tracers module; he may have been over enthusiastic
[09:45] <lifeless> anyhow the thing needed is glue <-> scripts
[09:51] <lifeless> meep
[09:51] <lifeless> once it drops out of cache fti is -realllllllllly- slow
[09:51] <wgrant> Even once stub attacks it with his magic wand?
[09:52] <lifeless> a wizzards staff has a knob on the end
[09:52] <wgrant> Shh.
[09:52] <lifeless> lpmain_staging=> explain analyze SELECT COUNT(CASE WHEN Bug.fti @@ ftq('sphinx') THEN TRUE ELSE null END) FROM Bug, BugTask WHERE BugTask.bug = Bug.id AND BugTask.distribution = 1;
[09:52] <lifeless> (8 rows)
[09:52] <lifeless> Time: 109213.606 ms
[09:52] <wgrant> what.
[09:53] <lifeless> lpmain_staging=> select count(*) from bug, bugtask where Bug.id = BugTask.bug AND BugTask.distribution = 1 AND Bug.fti @@ ftq('sphinx');
[09:53] <wgrant> Tried the query that has a less awful plan?
[09:53] <lifeless>  Time: 54666.999 ms
[09:53] <wgrant> Ow.
[09:53] <lifeless> still
[09:53] <lifeless> better is, well, better.
[09:53] <wgrant> But still utterly awful.
[09:53] <lifeless> shrug
[09:53] <lifeless> one step at a time
[09:55] <rockstar> Does launchpad_ftest have a different permission file than database/schema/security.cfg
[09:55] <lifeless> make schema to reset it
[09:56] <lifeless> ftest is built when you do make schema
[09:56] <lifeless> and thus only gets permissions built at that point
[09:56] <wgrant> rockstar: security.py is run only on launchpad_empty, so it should be the same.
[09:56] <lifeless> or whatever :P
[09:56] <rockstar> lifeless, that's what I suspected, but it doesn't seem to be working.
[09:56] <rockstar> launchpad_ftest is also created when the tests run, according to the postgres logs.
[09:57] <lifeless> yeah, I had the names wrong
[09:57] <wgrant> launchpad_empty is copied to launchpad_ftest_template
[09:57] <lifeless> its been a while
[09:57] <wgrant> launchpad_ftest_template has the sampledata loaded into it.
[09:57] <lifeless> I remembered the shape :P
[09:57] <wgrant> Then the testrunner copies launchpad_ftest_template to launchpad_ftest freshly for every test.
[09:57] <wgrant> No permission resetting is done after launchpad_empty, AFAIK.
[09:59] <wgrant> (if it was, tests would take a minute or two to set up...)
[10:02] <rockstar> They already take a minute or two to set up.
[10:03] <wgrant> Each test takes a second or so.
[10:03] <wgrant> The initial setup of the test suite around 10 seconds, here.
[10:04] <wgrant> Do you use LP_PERSISTENT_TEST_SERVICES?
[10:04] <lifeless> garh
[10:04] <lifeless> stab stab
[10:04] <lifeless> terrible idea.
[10:04] <wgrant> It saves time :)
[10:04] <rockstar> wgrant, I do.
[10:04] <wgrant> Lots of time.
[10:04] <wgrant> Almost makes TDD plausible.
[10:05] <lifeless> its curing the symptom
[10:05] <lifeless> but adding more root causes.
[10:09] <rockstar> lifeless, +1
[10:10] <rockstar> "Why am I starting up a librarian when my tests don't need one"
[10:12] <wgrant> Yeah, can we please do away with layers?
[10:12] <bigjools> good morning
[10:13] <wgrant> Evening bigjools.
[10:13] <bigjools> g'day wgrant
[10:15] <rockstar> lifeless, does this look okay for that branch you reviewed already? http://pastebin.ubuntu.com/466891/
[10:16] <wgrant> bigjools: When you have a moment, can you glance at https://code.edge.launchpad.net/~wgrant/launchpad/link-uploaded-ddebs/+merge/29669 and tell me if you object strongly to its approach?
[10:18] <bigjools> looking
[10:18] <lifeless> rockstar: yes
[10:23] <bigjools> wgrant: good approach, just a few comments
[10:23] <bigjools> wgrant: unit tests please, not tests in doctests
[10:24] <bigjools> wgrant: also consider factoring out your new code so you can write unit tests for it
[10:24] <bigjools> Running the upload processor in tests is something I want to reduce, not increase ;)
[10:26] <bigjools> wgrant: finally, my alarm bells go off very strongly when I see removeSecurityProxy being used in code
[10:26] <wgrant> bigjools: Fair point.
[10:26] <wgrant> In my defense, it's a reasonably large test to rewrite, and I revived this branch from October last year. I'll probably replace nascentupload-ddebs.txt in a separate branch.
[10:26] <bigjools> ok
[10:26] <wgrant> And yes, I strongly considered factoring that out.
[10:27] <bigjools> you should XXX it and file a bug plz
[10:27] <wgrant> But it means a significant restructure, so... maybe for another branch.
[10:27] <bigjools> that's fine
[10:27] <bigjools> thanks for fixing ddebs!
[10:27] <wgrant> I want Soyuz cleaned up too, don't worry.
[10:27] <wgrant> How can I avoid the rSP use?
[10:28] <bigjools> why is it needed?
[10:28] <wgrant> BPRs are traditionally immutable.
[10:28] <wgrant> But I need to set debug_package on some of them, after I have created them all.
[10:29] <wgrant> I guess I could create all the ddebs first, then the debs. Hmm.
[10:29] <bigjools> where does the bpr come from?
[10:29] <bigjools> as in, what creates the storm obj?
[10:29] <wgrant> The set of uploaded BPRs is created. I then create links between some of them.
[10:30] <wgrant> Um.
[10:30] <wgrant> I forget.
[10:30]  * wgrant finds.
[10:30] <bigjools> if it ultimately comes from getUtility then it's security wrapped
[10:30] <bigjools> but this all runs zopeless, so I don't understand why rSP is needed
[10:30] <lifeless> are my feet ok there?
[10:31] <wgrant> It's Build.createBinaryPackageRelease, so it's wrapped.
[10:31] <wgrant> bigjools: It still uses PermissiveSecurityPolicy.
[10:31] <wgrant> Zopeless is not Zopeless.
[10:31] <lifeless> rockstar: are my feet ok there?
[10:31] <rockstar> lifeless, yup.
[10:32] <bigjools> I realise - but I thought that since you're not actually logged in, it can't apply security
[10:32] <wgrant> PermissiveSecurityPolicy still cares about permissions. It's just that all permissions are implicitly held.
[10:32] <bigjools> other than interface checks
[10:32] <bigjools> exactly
[10:32] <wgrant> And nobody has permission to write to BPR.
[10:32] <bigjools> so, why is it grumbling about that
[10:32] <bigjools> ah
[10:32] <bigjools> that would explain it
[10:33] <bigjools> can you create the ddeb first then, and put it in the createBinaryPackageRelease params?
[10:33] <wgrant> I remember considering that when I wrote the code late last year... let's see if I can remember why I discarded that idea.
[10:33] <bigjools> ok
[10:36] <lifeless> stub: hai!
[10:36] <lifeless> stub: I have some info on fti for you
[10:36] <lifeless> stub: are you home or in transit ?
[10:37] <stub> lifeless: home
[10:37] <lifeless> so, the CASE approach used in nl_search takes about 10 times longer to do a search than a count(*)
[10:38] <lifeless> separately from considering whether doing an estimate + a search is worth it vs just doing a ranked search
[10:38] <lifeless> stub: are there some tests for nl_search I can build on ?
[10:39] <stub> I don't know - that was all bug team work. I only know it vaguely.
[10:39] <lifeless> ok
[10:39] <lifeless> uhm
[10:39] <lifeless> I will hunt bjorns
[10:40] <rockstar> Huh, I can't remember the reasoning for making people the base parent in recipe traversal.
[10:41] <rockstar> Whatever it is, my mind has been changed and I think that's crackful.
[10:41] <wgrant> The form should at least inform users that the recipe names are global.
[10:42] <rockstar> wgrant, it does now.
[10:42] <wgrant> Ah.
[10:42] <rockstar> Well, it does when you try and re-use a name.
[10:42] <rockstar> The problem is that I want more than one recipe named "daily" ...
[10:42] <wgrant> I often try to call a recipe 'trunk'.
[10:42] <wgrant> Right.
[10:43] <rockstar> It should have also traversed to project or sourcepackage
[10:44] <rockstar> "Paul Hummer's daily recipe" is silly
[10:44] <wgrant> What happened to ~wgrant/launchpad/+recipe/daily?
[10:45] <rockstar> Basically it means that I'm going to invent my own namespace.
[10:45] <wgrant> I thought the initial proposal was something like that.
[10:45] <rockstar> wgrant, yeah, but there was some reason for not doing it.
[10:46] <rockstar> (I'm saying that now that abentley and I have implemented it, that reason is shit)
[10:47] <wgrant> Haha.
[10:48] <lifeless> ok
[10:49] <lifeless> so bugs -> db -> stub -> bjorn -> flacoste
[10:49] <lifeless> but I now have enough confidence in the issue: deleting painful code.
[10:50] <rockstar> bigjools, could you maybe give me some hints here: https://bugs.edge.launchpad.net/launchpad-code/+bug/591618
[10:50] <_mup_> Bug #591618: Result of SPRBuild assumes distro build <recipe> <Launchpad Bazaar Integration:Incomplete by rockstar> <https://launchpad.net/bugs/591618>
[10:50] <bigjools> rockstar: gimme some time, I'm fighting canonicaladmin
[10:54] <rockstar> bigjools, it will take AGES to defeat canonicaladmin though!
[10:54] <bigjools> rockstar: this is just the battle, for the war, totally
[10:54] <rockstar> :)
[10:58] <danilos> adiroiban, jtv, woohoo, +templates works on edge (rendered https://translations.edge.launchpad.net/ubuntu/lucid/+templates in 6.52s)
[10:58] <jtv> danilos: yay!
[11:00] <jtv> danilos: that's with figuring out the menu links just once for the entire page?
[11:00] <jtv> Hmm.... it just timed out for me.
[11:01] <adiroiban> danilos: sometimes I get a time out on Ubuntu
[11:01] <adiroiban> openobjects-addons is 0.6s
[11:01] <danilos> adiroiban, jtv: yeah, we still have it time-out occasionally because of the rendering times, but still, it worked for me :)
[11:02] <danilos> karmic consistently times out for me but it does have a lot more templates on there
[11:03] <jtv> I got one loaded!
[11:04] <jtv> On the 3rd attempt though.
[11:04] <jtv> The mouse-over effect doesn't seem to be working... maybe one of the extra files failed to load.
[11:05] <danilos> jtv, adiroiban: I guess we'll either have to fix rendering time (I talked to gary_poster and he mentioned switching to a faster TAL-rendering library chameleon as an option)
[11:05] <danilos> jtv, adiroiban: or batch it :)
[11:13] <bigjools> ok rockstar let's check out your branch
[11:13] <rockstar> bigjools, it's just a bug, but I have a test in there that I can't get to act like production.
[11:13] <rockstar> bigjools, noodles is also sitting right next to me, and so I was going to ask him.
[11:14] <bigjools> rockstar: I think what should happen is that canonical_url should return None for a package built in a PPA
[11:14] <bigjools> and then you can change the template code to not link it
[11:14] <rockstar> bigjools, yes, I know this.
[11:14] <rockstar> bigjools, the problem is that I can't reproduce this in a tests.
[11:14] <bigjools> ok
[11:15] <rockstar> bigjools, so I'm wondering where the formatter is so I can see why it's not linking it in my test.
[11:15] <bigjools>         release = self.factory.makeSourcePackageRelease(
[11:15] <bigjools>             source_package_recipe_build=None)
[11:15] <bigjools>         release.source_package_recipe_build = build
[11:15] <bigjools> why 2 lines?
[11:15] <bigjools> transaction.commit() - urg :)
[11:15] <rockstar> bigjools, good question.
[11:15] <bigjools> why do you need to commit?
[11:16] <bigjools> rockstar: so I think you also need to assert in that test that the build's archive is a PPA
[11:16] <rockstar> bigjools, that test is the result of late afternoon hacking, and trying whatever I can to make it work.
[11:16] <bigjools> ok
[11:17] <bigjools> does makeRecipeBuild() default to a PPA?
[11:18] <rockstar> I think it takes the default archive.
[11:18] <bigjools> I'd add the assertion in the test
[11:19] <rockstar> bigjools, where is the formatter?  I was thinking I would find it after I got the test working, because it wasn't clear.
[11:19] <bigjools> rockstar: what formatter?
[11:19] <rockstar> The SourcePackageReleaseFormatter in tales.py didn't seem to be it.
[11:20] <rockstar> bigjools, the tal formatter for a source package release
[11:20] <bigjools> there isn't one
[11:20] <rockstar> bigjools, huh?  Then how is it getting linked?
[11:20]  * rockstar cries
[11:20] <bigjools> does the template do it?
[11:21] <bigjools> anyway, your test is asserting the wrong thing isn't it?
[11:21] <rockstar> bigjools, no, it passes it to fmt:link
[11:21] <bigjools> ok
[11:21] <rockstar> bigjools, no, it's asserting that it's plain text, not linked.
[11:21] <bigjools> it's still wrong
[11:21] <rockstar> And it SHOULD be failing, but it's not.
[11:21] <bigjools> it's not a distribtion package
[11:21] <bigjools> so you're asserting that the current state of affairs is correct
[11:21] <bigjools> which of course it always is :)
[11:22] <bigjools> fmt:link just does canonical_url on the object
[11:22] <rockstar> bigjools, so are you saying we should take the whole thing out?  Don't even show a release?
[11:22] <bigjools> it should say "Package X in PPA blah"
[11:23] <bigjools> or something
[11:23] <poolie> is there any other lib.lp.service module that sets a good example for code or test style?
[11:23] <rockstar> bigjools, yes, and I'm saying "Where is the code that names out that template?"
[11:23] <bigjools> is there a real example I can see?
[11:23] <bigjools> I dunno, it's one of yours isn't it?  +recipe page?
[11:24] <rockstar> bigjools, https://code.edge.launchpad.net/~rockstar/+recipe/daily/+build/348
[11:24] <bigjools> ok let's take a looksee
[11:25] <bigjools> ah I see
[11:25] <bigjools> rockstar: junk the whole section
[11:25] <rockstar> bigjools, the template is just using existing code.  I believe abentley even just abstracted the original build index.
[11:25] <rockstar> bigjools, really?!
[11:25] <bigjools> yes, it doesn't make any sense for a PPA build
[11:25] <bigjools> there's no package page on PPAs
[11:25] <rockstar> bigjools, it's a good thing you're in a different country, because I REALLY wanna kiss you right now.
[11:25] <bigjools> lol
[11:26] <bigjools> so "Result:" and the line below it - blow them away
[11:26] <bigjools> or if you're in a kissing mood, just blow them
[11:26] <rockstar> bigjools, could you comment on the bug with something like that?
[11:26] <bigjools> sure
[11:26] <rockstar> ...and I'll happily just kill it.
[11:28] <bigjools> rockstar: the binary builds are plenty good enough to detail what was built
[11:32] <rockstar> bigjools, I agree.
[11:36] <poolie> lifeless, igc says 'congrats'
[11:38] <lifeless> poolie: thanks! - tell him best wishes !
[11:48] <lifeless> https://code.edge.launchpad.net/~lifeless/launchpad/malone/+merge/30507 if anyone is interested :)
[11:54] <barry> bigjools: hi.  on my ppa package details page i occasionally see (Newer version available).  is this information available in the api?
[11:56] <lifeless> barry: yes
[11:56] <barry> lifeless: is this the superseded stuff in the build records?
[11:57] <lifeless> nah, its a reference to the suite in ubuntu
[11:59] <barry> lifeless: okay, thanks. i'll try to find it ;)
[12:00] <bigjools> I think it's only on the UI actually
[12:00] <gary_poster> danilo: re chameleon: fwiw, in my measurements last year it saved an average of 15% from page times.  not too shabby, but not a silver bullet.  in the big picture, for common pages, network and SSL and client-side issues dwarf app-server times; and for most OOPSes we have, db time dwarfs rendering times.  but chameleon should help somewhat.  It would probably be more of a benefit for big honking pages like the on
[12:00] <gary_poster> talking about.
[12:01] <gary_poster> probably was truncated: "but chameleon should help somewhat.  It would probably be more of a benefit for big honking pages like the one you were talking about."
[12:01] <barry> bigjools: ah.  what i'm trying to do is script auto-rebuilds for packages in the ppa that are now out of date.  basically: search to find them, apt-get source, dch -i, build -S, dput
[12:02] <bigjools> barry: ummm, why are you duplicating builds in Ubuntu?
[12:03] <bigjools> or are there extra local changes?
[12:03] <barry> bigjools: they are builds of packages that build-dep on python-all and python-dev-all.  i build them in the ppa to pick up python 2.7
[12:03] <wgrant> And to destroy the build farm for 1.5 weeks :)
[12:03] <bigjools> exactly
[12:04] <barry> wgrant: not any more :)
[12:04] <bigjools> if you want to do rebuilds, you should use a rebuild archive
[12:04] <bigjools> or your good name is going to be mud :)
[12:04] <barry> bigjools: i really *don't* want to rebuild vast numbers of packages.  only about 150 of them
[12:04] <barry> bigjools: your flaw is assuming i ever had a good name
[12:05] <bigjools> barry: ah ok so you're rebuilding packages where its build deps changed?
[12:05] <bigjools> barry: ok, s/mud/muddier/ :)
[12:05] <barry> bigjools: yeah :)
[12:05] <barry> bigjools: but as updates get thrown in the archive, i have to essentially re-sync them, but i think you can't do that (or can you?)
[12:06] <bigjools> rockstar: err sorry I changed your bug status, it said "incomplete" on my browser, honest :)
[12:06] <bigjools> we could do with collision detection there
[12:06] <barry> bigjools: otherwise, apt-get update && apt-get upgrade will pick up the newer, non-py27 versions instead of the py27-built versions i want from my ppa
[12:06] <deryck> Morning, all.
[12:07] <bigjools> barry: you can copy from Ubuntu into your PPA very easily using the API
[12:07] <barry> bigjools: syncSources?
[12:07] <bigjools> barry: you can pin on your PPA too
[12:07] <bigjools> and syncSources, yes
[12:07] <barry> bigjools: yeah, i could do that
[12:08] <bigjools> pinning would be better
[12:08] <bigjools> fewer rebuilds ;)
[12:08] <barry> bigjools: <cough>more (efficient) buildds</cough> :)
[12:09] <bigjools> in progress ;)
[12:09] <barry> bigjools: :)
[12:09] <bigjools> jelmer and myself are making buildd-manager changes that will rock the world
[12:09] <barry> bigjools: i'd love to hear more!  but it's lunch time so i'll come back and ask
[12:12] <gary_poster> barry: I've been seeing if I could get buildout tests to pass with 2.7.  is there a known issue for Python 2.7 that output from both spawn and subprocess is...held, for some reason?
[12:12] <gary_poster> For example, given hacked code like this http://pastebin.ubuntu.com/466949/ (and I've hacked to use both spawn and subprocess in tests), including that half second sleep, I get failures like this: http://pastebin.ubuntu.com/466950/ .
[12:12] <gary_poster> (IOW, the "An error occurred..." should be printed below the output from the subprocess call, but is not).
[12:12] <gary_poster> So, known?  I'm about to give up.
[12:13] <gary_poster> (2.4, 2.5, 2.6 don't behave this way)
[12:22] <wgrant> bigjools: removeSecurityProxy call gone.
[12:22] <bigjools> woo
[12:22] <wgrant> I shuffled things around a bit, creating the ddebs first and a couple of other bits and pieces.
[12:24] <bigjools> argh, I am finding it impossible to read email quicker than it arrives today
[12:24] <bigjools> death to email from machines
[12:24] <bigjools> email is for people fer chrissake
[12:27] <bigjools> lifeless: I've got another candidate to use for Rabbit if it's close to being implemented
[12:32] <lifeless> bigjools: it needs someone to put a layer together + lazr-config schema entry for it
[12:33] <lifeless> bigjools: at that point we have all the bits in place to iterate.
[12:33] <bigjools> cool
[12:33] <bigjools> lifeless: I want to put the new distroseries opening code (initialise-from-parent) on it
[12:33] <bigjools> Steve is working on making it a Job
[12:33] <wgrant> Whatever happened to CHR?
[12:36] <deryck> wgrant, it's still happening, but I think some confusion in the change to the new approach and new days has slipped coverage lately.
[12:37] <deryck> wgrant, it's Edwin's day today, but he's not around yet.
[12:38] <bigjools> deryck: when someone updates a bug status, do you detect collisions? (with a second person updating it)
[12:39] <deryck> bigjools, no.  we just have the latter one overwrite the first attempt.
[12:41] <bigjools> deryck: do you have bugs about that?  If not I think I should file one :)
[12:41] <lifeless> mtaylor: hi
[12:41] <lifeless> bah
[12:41] <lifeless> mthaddon: hi
[12:42] <lifeless> mthaddon: could you do me a small favour? on staging, up the timeout to 20 seconds, I want to test a theory about whats going on here.
[12:42] <deryck> bigjools, there is a "show edits in real time" bug, which is basically the same, but perhaps your issue is a bit more specific?
[12:43] <bigjools> deryck: I changed a status from incomplete to triaged, but because I had not loaded the page recently I didn't see that someone else had changed it from incomplete to in-progress
[12:43] <bigjools> so I override his change
[12:44] <bigjools> seems like we could simply check the status we're changing from and see if the status on the bug now is still the same
[12:45] <deryck> hmmm, yeah, I think that could use a new bug.  That's a simpler change than real time edits and would bring value now.
[12:46] <lifeless> deryck: bigjools: landscape has a jobs system too which they say they use for ajax notifications
[12:46] <bigjools> lifeless: yeah I replied to their thread
[12:46] <lifeless> its slightly different in concept to ours
[12:46] <lifeless> cool
[12:46] <bigjools> it sounds great
[12:46] <lifeless> I'm pulling on this thread
[12:46] <bigjools> deryck: ok I'll file a bug for you, cheers
[12:46] <deryck> yeah, it does sound nice.  That would make real time edit notifications possible, I believe.
[12:47] <lifeless> yeah
[12:47] <deryck> bigjools, thanks.
[12:47] <lifeless> separate to mid flight detection
[12:47] <deryck> right
[12:47] <bigjools> deryck: BTW my mental picture of you has now shifted unassailably to one where you're playing Dominion and sledging your opponents
[12:48] <deryck> heh
[12:48] <deryck> I perhaps was a bit too relaxed at the epic.  I normally hide that part of myself.  :-)
[12:49] <deryck> gaming brings out the worst in me.
[12:49] <bigjools> deryck: lol
[12:50] <bigjools> yeah me too - I hardly play any more.  I got asked by neighbours once to stop swearing so loudly.  I've since moved to somewhere where I don't have close neighbours.
[12:50] <deryck> heh.  I can relate.
[12:50] <bigjools> That's Counterstrike for you ...
[12:56] <bigjools> food time
[13:06] <lifeless> losa ping
[13:16] <mthaddon> lifeless: hi
[13:16] <lifeless> mthaddon: hi
[13:17] <lifeless> mthaddon: I was wondering if you could raise the timeout on staging temporarily, I want to get a full trace of what this does
[13:17] <lifeless> that slow query, once its not fighting disk - 300ms
[13:19] <mthaddon> lifeless: done
[13:19] <lifeless> \o/
[13:19] <lifeless> try this
[13:19] <lifeless> go to
[13:19] <lifeless> https://bugs.staging.launchpad.net/ubuntu/+filebug
[13:19] <lifeless> put in a search
[13:20] <lifeless> click next
[13:20] <lifeless> everyone^
[13:20] <mthaddon> lifeless: I increased the softtimeout as well - should I have left that as is?
[13:20] <wgrant> WoahJSbug.
[13:20] <wgrant> Oh, no, Chromium bug.
[13:21] <lifeless> mthaddon: no, thats fine
[13:21] <lifeless> mthaddon: the main thing was to get enough headroom to see how it performs on this slower hardware
[13:21] <lifeless> I am getting 2-3 second searches
[13:21] <barry> gary_poster: no bug or change that i know of :/
[13:23] <lifeless> mpt: ^ what do you think?
[13:24] <lifeless> deryck: ^ you too, and I think I'll have enough confidence to say we should give this a spin
[13:24] <mpt> lifeless, I tried "Internet doesn't work on Broadcom". It returned decent results (though I have no idea what they're missing), but took 25 seconds.
[13:25] <deryck> lifeless, sorry, me too what?  Search at ubuntu filebug on staging?
[13:25] <lifeless> mpt: ok; please try again
[13:25] <lifeless> deryck: yeah
[13:25] <mtaylor> lifeless: ola
[13:25] <lifeless> mpt: the search index appears to be very big, so not all fitting in memory on staging, which is tiny
[13:26] <mpt> "wobbly windows flicker": ~8 seconds, decent results
[13:26] <rockstar> lifeless, where are you physically?
[13:26] <lifeless> rockstar: in my room for the moment
[13:26] <lifeless> I'll be down shortly
[13:26] <rockstar> lifeless, ack.
[13:26]  * rockstar will be glad to go back to his desk tomorrow
[13:27] <lifeless> deryck: so this is a replacement pre-filter for bug searching
[13:27] <lifeless> deryck: I haven't audited the full stack, but if we feel this is decent we might want to CP it to prod
[13:27] <deryck> lifeless, yeah, pretty snappy response for me.  2-3 seconds on normal searches.  Lots of words returns in 5-6 seconds for me.
[13:27] <lifeless> deryck: does it feel comparable to prod for you, or better ?
[13:27] <lifeless> [ignoring hardware]
[13:28] <deryck> lifeless, better actually.
[13:28] <lifeless> ok
[13:28] <lifeless> I shall do the do
[13:28] <lifeless> mthaddon: thanks, I'm finished with staging as a test env for this.
[13:29] <mthaddon> k
[13:29] <mpt> "install eclipse get unmet dependencies error": 13 seconds, and doesn't return bug 603656 at all.
[13:29]  * rockstar wonders how to capture mpt in a test
[13:29] <lifeless> mpt: does it on production ?
[13:31] <mpt> gnarrrrgh
[13:32] <mpt> lifeless, I can't test on production without leaving the beta testers team. On edge, the same search gives me a timeout.
[13:32] <lifeless> mpt: click the 'do not redirect me button'
[13:32] <mpt> oh of course
[13:32] <lifeless> mpt: if there isn't one, please (har har) file a bug because we should still show that even in a new ajax world
[13:32] <mpt> I don't see that button any more
[13:33] <mpt> It's supposed to be on http://launchpad.net/ right?
[13:33] <lifeless> mmm
[13:33] <lifeless> I thought so
[13:33] <deryck> mpt, lifeless -- I believe it's a link in the footer now.
[13:33] <wgrant> mpt: It's only shown on edge, and it's at the bottom.
[13:33] <wgrant> And it's not on the front page.
[13:33] <mpt> The footer for me is "© 2004-2010 Canonical Ltd.  •  Terms of use  •  Contact Launchpad Support  •  System status  •  Take our survey!"
[13:33] <mpt> and on edge, "© 2004-2010 Canonical Ltd.  •  Terms of use  •  Contact Launchpad Support  •  System status  •  Take our survey!  •  r11179 beta site"
[13:34] <mpt> oh, not on the front page
[13:34] <wgrant> Right.
[13:34] <wgrant> That would be too obvious :)
[13:34] <mpt> The footer doesn't change on other pages for me
[13:34] <lifeless> mpt: on the bug filing page
[13:35] <mpt> oh, wait, THAT footer
[13:35] <lifeless> bottom right, green
[13:35] <wgrant> It's in the non-footer footer.
[13:35] <wgrant> Right.
[13:35] <lifeless> this is special :(
[13:35] <mpt> The blue one as opposed to the white one
[13:35]  * mtaylor remembers days when he did web programming...
[13:36] <lifeless> times out on prod for me too
[13:36] <mpt> timeout for me too
[13:36] <lifeless> so
[13:36] <lifeless> prod does not show it either
[13:37] <gary_poster> ack, barry, thanks for looking
[13:38] <lifeless> mpt: thank you very much for playing with it; unless you say 'its a disaster' I'm going to move forward to get it on edge asap
[13:38] <mpt> It's not a disaster
[13:38] <mpt> afaict
[13:38] <lifeless> deryck: your opinion?
[13:39] <barry> gary_poster: np.  i'd be interested if you track it down to a bug in python
[13:39] <rockstar> lifeless, deryck's opinion may or may not involve comparisons to Windows 7, so tread carefully.
[13:39] <deryck> lifeless, I say move forward on it.  If timeouts don't happen on staging, we should be better on edge/prod too.
[13:39] <deryck> yes, if it's better than windows 7 bitches, I'm all in!
[13:39] <gary_poster> heh
[13:40] <gary_poster> barry: cool. I dunno if I'll take it that far, but we'll see
[14:29] <lifeless> when do we set things 'fix committed' ?
[14:29] <lifeless> ... do we set them to that ?
[14:30] <rinze> lifeless: When the change lands but hasn't been deployed
[14:30] <rinze> lifeless: Scripts will set them for us though
[14:32] <wgrant> bigjools: Did you get around to the PPA log parser thing you were looking at a couple of weeks ago.
[14:35] <bigjools> wgrant: not yet, sorry.  The code and config is all in though, we just need to turn it on
[14:36] <wgrant> bigjools: Even the row-limiting config?
[14:37] <bigjools> yes
[14:43] <wgrant> Excellent.
[14:44] <bigjools> life would be so much easier if I could block new bugs on soyuz
[14:44] <lifeless> tell you what
[14:45] <lifeless> ship code with less bugs, less bugs will be filed ;)
[14:47] <bigjools> Or I can use Jedi mind tricks.  These aren't the bugs you're looking for.
[14:47]  * bigjools waves hand
[14:48] <wgrant> Do the Jedi mind tricks involve LOSAs and DELETE FROM bugtask?
[14:49] <lifeless> no
[14:49] <lifeless> :)
[14:49] <bigjools> uh what?  Sorry, my mind had drifted to Princess Leia and 'that' outfit
[14:50] <lifeless> a danish on each ear
[14:50]  * mthaddon was picturing bacon on Leia's ears...
[14:51]  * bigjools just spurted a mouthful of coffee
[14:52] <lifeless> rotfl
[14:53] <bigjools> mthaddon: I didn't know Jono was in Star Wars
[14:54] <mtaylor> lifeless: really need one more bug status man
[14:54] <mtaylor> lifeless: fix committed, fix merged and fix released...
[14:54] <mtaylor> just saying
[14:54] <lifeless> meh
[14:54] <mtaylor> three different things, important to three different sets of people
[14:54] <lifeless> less actually
[14:55] <lifeless> overly precise is not always good
[14:55] <lifeless> committed where, merged where, released where.
[14:55] <mtaylor> indeed
[14:55] <lifeless> really, we want 'done in context' and many contexts: more flexible, more power, nuke bugtasks too
[14:55] <mtaylor> for that matter - what the hell does "committed" mean
[14:55]  * lifeless handwaves furiously about stuff in deryck's domain
[14:56]  * deryck welcomes domain intrusion and hand-wavery
[14:56] <mtaylor> I just want to know: a) when there's a tree claiming to fix it on launchpad somewhere- when that has hit trunk, and when that has hit a "release"
[14:56] <mtaylor> hrm
[14:56] <mtaylor> I should have injected the b and the c there
[14:57] <mtaylor> imagine them
[14:57] <lifeless> sure
[14:57] <lifeless> see, that fits my model better :P
[14:57] <mtaylor> good
[14:59] <lifeless> flacoste: btw, I'm changing how answers search works :P
[15:02] <flacoste> lifeless: ok, why?
[15:04] <lifeless> because its the cause of about 8 seconds overhead on searching bug dups
[15:04] <lifeless> its doing work that the fti index should do
[15:04] <lifeless> causing a scan of every bug, ever, in the context of the search
[15:05] <lifeless> flacoste: the change shouldn't be very visible to users, based on some brief testing we did on staging.
[15:05] <lifeless> flacoste: but if we do need to change the ranking we should do that at the tsearch2 layer
[15:06] <flacoste> interesting
[15:07] <flacoste> how a search within answers cause an 8 seconds overhead on search bug dups?
[15:07] <lifeless> the nl_search code
[15:07] <lifeless> common code path
[15:07] <lifeless> its also causing timeouts in answers
[15:08] <lifeless> flacoste: https://code.edge.launchpad.net/~lifeless/launchpad/malone/+merge/30507 - the old code is kept so we can really easily reenable if we don't like this.
[15:13] <flacoste> lifeless: ok, the quality of results will decrease significantly
[15:13] <flacoste> but let the user determine that
[15:13] <flacoste> the slow algorithm is based on MySQL implementation of full text search
[15:13] <lifeless> flacoste: I'd like to iterate and make it better
[15:13] <lifeless> yeah
[15:13] <flacoste> which gives very good result
[15:14] <flacoste> plain tsearch2 search sucks
[15:14] <lifeless> so what it does to use is due to not using their entire implementation
[15:14] <lifeless> s/use/us/
[15:14] <flacoste> which is fast :-)
[15:14] <lifeless> we end up scanning every object in the context, across the board.
[15:14] <lifeless> which is a lot of work
[15:14] <lifeless> - 8 seconds on ubuntu, and growing: for a *single* term
[15:14] <lifeless> when we have multiple terms, its worse.
[15:15] <lifeless> because we're consulting the fti vector per-row
[15:15] <lifeless> per-term
[15:15] <lifeless> this is why multi term searches time out more than single term searches
[15:15] <lifeless> I am proposing this as a band aid
[15:15] <lifeless> get us some headroom
[15:15] <flacoste> that's fine
[15:16] <lifeless> and we'll either use tsearch2 better, or drop in an entirely dedicated search engine
[15:16] <lifeless> great, thanks.
[15:16] <lifeless> the replacement query, FWIW, is ~ 500ms on staging
[15:17] <lifeless> (once disk IO is excluded)
[15:17] <flacoste> and maybe tsearch2 ranking has gotten better over the year
[15:17] <lifeless> stub says we haven't tuned it at all
[15:17] <lifeless> you're meant to write your own rank function anyhow
[15:18] <lifeless> flacoste: thanks; I'm going to focus on the landscape/server guys now for a bit
[15:36] <deryck> gary_poster, ping
[15:36] <gary_poster> deryck: pong
[15:50] <jml> lifeless, not sure whether the 'tracer' discussion above got resolved
[15:50] <jml> lifeless, there's code similar to what's in https://pastebin.canonical.com/34889/ in lp/testing/__init__.py, iirc.
[16:07] <leonardr> poolie, iirc you said yesterday you were okay with the current implementation of https://code.edge.launchpad.net/~leonardr/launchpadlib/improve-workflow/+merge/29849. if that's true, can you mark as approved? otherwise, comment with the change you want me to make
[16:10] <lifeless> jml: neither am I :)
[16:11] <jml> lifeless, ok.
[16:21] <lifeless> deryck: ping - bug 600934
[16:21] <_mup_> Bug #600934: BugSubscription table need a constraint to prevent people being subscribed twice to the same bug <story-better-bug-notification> <Launchpad Bugs:Won't Fix by brian-murray> <https://launchpad.net/bugs/600934>
[16:22] <deryck> lifeless, yup.  know it well.  wasn't sure if we should have marked it won't fix, but haven't got back to it today yet.
[16:23] <lifeless> deryck: seems to me that merging people should merge their subs too, no ?
[16:24] <lifeless> the merge code is approachable; wearing my maintainablity / data hygiene hat - this is totally something we should fix
[16:25] <deryck> lifeless, agree.  But this wasn't was Brian was looking into, and sinzui seemed to suggest this was difficult to fix.
[16:26] <lifeless> we wrote the code in the first place :)
[16:26] <sinzui> lifeless, I have argued fixing merge for more than a year. The work is *always* considered out of scope
[16:27] <lifeless> sinzui: we're agreed then that we should fix it.
[16:27] <lifeless> sinzui: thats plenty for me; I know how scheduling works. If its considered really tricky, I'll happily mentor someone on it.
[16:27] <sinzui> No one agrees it it is worth one cycle
[16:27] <lifeless> its worth a couple of days, tops.
[16:28] <deryck> sinzui, where does this code live in the tree?
[16:28] <lifeless> less ~/Desktop/Downloads/signature.asc
[16:28] <lifeless> bah
[16:29] <sinzui> I have a script I am considering for a garbo job. to cleanup some of the data /after/ a merge. But the correct solution (and certainly assumed by brian's change) is to make merge an out of proc task that has a chance to succeed. eg, to take 27 patient tries to complete a merge of ~barry
[16:30] <lifeless> sinzui: are we hitting write contention ?
[16:30] <lifeless> merge should be an out of webapp thing *anyway*
[16:30] <lifeless> the whole merge operation, I mean.
[16:30] <sinzui> deryck, person merge...but keep in mind. We want to start new features, but we seem to be working on performance instead.
[16:30] <lifeless> sinzui: in the eyes of our stakeholders, performance is as much a feature as anything else.
[16:31] <sinzui> lifeless, There is too much work to do in a merge to happen in a single request.
[16:31] <lifeless> sinzui: ack - agreed. Thus my comment that it shouldn't be done in the webapp transaction *anyway*
[16:31] <sinzui> lifeless: I think everyone needs agree with what my team is working on, privacy, timeouts, or merge.
[16:32] <lifeless> sinzui: I'm happy to consider the bug in question medium or even low priority
[16:32] <lifeless> sinzui: I have no view on its urgency
[16:32] <deryck> lifeless, sinzui -- so if we want the constraint bug kept around to track this, I'm fine, but I think it needs fixing up to generally represent this issue.
[16:33] <lifeless> deryck: sounds good to me
[16:33] <deryck> I also do think it's out of scope for our current subscription work, and would call it low priority for the bugs team, compared to everything else.
[16:33] <lifeless> sinzui: we have the team leads call this evening and perhaps we can refine what we're doing in that call
[16:34] <MTecknology> So... auto-fill for tags.. That's an awesome feature that never crossed my mind.
[16:34] <sinzui> The bugs are reported every release, the questions are reasked. One issue is number 8 in bug heat: and then there is my old blueprint that gives a broader view of the issues: https://blueprints.edge.launchpad.net/launchpad-registry/+spec/cleansing-deactivated-accounts
[16:34] <lifeless> sinzui: what does 8 in heat mean - is that high ?
[16:34] <sinzui> It is the 8th item in heat
[16:35] <lifeless> ok
[16:35] <sinzui> karma bugs collectively dominate registry heat
[16:48] <poolie> leonardr, do it!
[17:04] <lifeless> flacoste: what is the mechanism for the call in 2 hours ?
[17:07] <bigjools> lifeless: Francis' conf line
[17:28]  * bigjools shoots and scores, new buildd-manager working on dogfood working like a champ
[17:29] <bigjools> jml: don't suppose you fancy reviewing it do you?  I fear someone else would vomit at the horrendous twisted hacks.
[17:42] <jml> bigjools, sure, but I won't get around to it today
[17:42] <jml> bigjools, my mind feels like stale custard
[17:42] <bigjools> jml: I wasn't expecting you to - thanks very much.  Maybe we can mumble over it later this week.
[17:43] <bigjools> jml: there's some dodgy tests that you might be able to help me make nicer
[17:45]  * jml afk
[18:25] <poolie> jam, rockstar, hi, want to meet for dinner?
[18:26] <rockstar> poolie, as long as I don't have to wait much longer.
[18:26]  * rockstar is starvin' Marvin.
[18:26] <poolie> ready now if you are
[18:26] <rockstar> poolie, lemme pack up then.
[18:26] <poolie> i'd like to go to the place on the plaza near here
[18:26] <poolie> the google reviews are good
[18:26] <jam> poolie: certainly
[18:26] <rockstar> poolie, sure, as long as it's fast.
[18:27] <poolie> kk :)
[18:27] <poolie> COME ON! WE HAVE A 5 SECOND TIME OUT!
[18:28] <jam> poolie: see you in the lobby in about 5min
[18:28] <poolie> great
[18:43] <danilos> anyone remembers where's the documentation for those query counting functions (or at least what they are) that thumper introduced a while back?
[18:49] <thumper> danilos: assertQueryCount I think
[18:50] <danilos> thumper, thanks (damn missing -i option on my grepping exercise)
[18:51] <danilos> thumper, though, I still can't find it being used anywhere
[18:52] <thumper> danilos: I'm pretty sure it is used in some code tests
[18:53] <danilos> thumper, that's what I was grepping, I guess it's just a long day
[18:53] <thumper> danilos: assertStatementCount
[18:53] <thumper> sorry
[18:53] <danilos> thumper, right, just as I found it inside __init__.py of lib/lp/testing :)
[18:55] <danilos> thumper, np, we should probably move jtv's old query counter for +translate page to this as well
[18:55] <thumper> yup
[18:56] <danilos> thumper, or well, maybe not because that one counts them for the entire request being rendered
[19:33] <rockstar> thumper, hi!
[20:00] <m4n1sh> anyone here can help me with setting up launchpad?
[20:00] <lifeless> !ask
[20:01] <m4n1sh> i tried "make schema"
[20:01] <lifeless> m4n1sh: just ask away, asking for a dedicated helper usually doesn't work in public channels ;)
[20:01] <m4n1sh> Missing ./download-cache.
[20:01] <m4n1sh> Developers: please run utilities/link-external-sourcecode.
[20:01] <m4n1sh> make: *** [download-cache] Error 1
[20:01] <lifeless> have you followed the wiki pages on setting it up
[20:01] <m4n1sh> on running https://dev.launchpad.net/Running
[20:01] <m4n1sh> this page? right?
[20:01] <lifeless> thats the second one
[20:01] <lifeless> Getting is the first one
[20:02] <m4n1sh> i got the edgde code
[20:02] <m4n1sh> not devel
[20:02] <m4n1sh> *edge
[20:02] <lifeless> we don't use the edge code
[20:02] <lifeless> we work on devel
[20:02] <lifeless> please follow the 'getting' wiki page, you've skipped a lot of steps
[20:03] <m4n1sh> oh crap
[20:03] <m4n1sh> i missed so much
[20:03] <m4n1sh> lifeless, thanks for pointing it out
[20:04] <lifeless> np
[20:16] <lifeless> thumper: hi
[20:16] <lifeless> thumper: uhm, salgado I think it was, was mentioning that the branch listing page is still having trouble with things with lots of bugs linked, or something
[20:18] <lifeless> its a little freaky to have windmill opening browser windows in my host os when running tests in my vm
[20:18] <lifeless> just saying
[20:23] <thumper> lifeless: file a bug with an oops id and I can check it out
[20:37] <lifeless> thumper: I told him just that :)
[20:45] <lifeless> rockstar: up still ?
[20:51] <rockstar> lifeless, yes.
[20:52] <lifeless> #lp-reviews, if you have time
[21:28] <benji> anyone ever run into a pylint warning that can't be silenced?  I added a # pylint: disable-msg=E0221
[21:28] <benji> ...and it's still complaining.
[22:08] <lifeless> I'm off to bed
[22:08] <lifeless> gnight
[22:08] <benji> night
[22:11] <flacoste> poolie: i think you picked the bad branch to merge into, as your diff is huge
[22:11] <poolie> i know!
[22:11] <flacoste> poolie: that's on https://code.launchpad.net/~mbp/launchpad/flags/+merge/30580
[22:11] <poolie> lifeless has just pointed that out
[22:11] <lifeless> just think
[22:11] <poolie> i know :)
[22:11] <poolie> i actually realized myself
[22:11] <lifeless> this *won't happen* anymore in about 6 weeks
[22:11] <lifeless> or less.
[22:11]  * lifeless is really gone.
[22:12] <poolie> never mind the length, feel the quality!
[22:12] <benji> heh
[22:15] <poolie> uh is this continuing fallout from people renaming branches?
[22:15] <poolie> db-devel seems to be gone
[22:24] <maxb> poolie: gone?
[23:18] <wgrant> Hmm.
[23:18]  * wgrant wonders why ShipIt hasn't been split out yet.
[23:19] <wgrant> Even if ISD can't be bothered rewriting it, it could surely just run on a separate DB with an old, static version of LP...
[23:19] <benji> wgrant: it would help me if it were split out; I could fix two or three LP bugs by deleting data that LP doesn't use but ShipIt does
[23:20] <wgrant> Then we could destroy Account, and safely remove stuff without having to check in history if ShipIt used it.
[23:21]  * rinze waves to wgrant and benji
[23:22] <wgrant> Morning rinze.
[23:30] <mwhudson> wgrant: just lack of tuits i think
[23:47] <wgrant> When is the Lucid upgrade happening?
[23:48] <wgrant> And is there any OCR happening this week, or should I seek out another reviewer?
[23:51] <rinze> wgrant: What sort of review do you need/
[23:51] <rinze> I mean, what kind of branch
[23:52] <rinze> ?
[23:52] <wgrant> rinze: It's a nascentupload branch. https://code.edge.launchpad.net/~wgrant/launchpad/link-uploaded-ddebs/+merge/29669
[23:52] <wgrant> bigjools has already approved the direction.
[23:54] <rinze> wgrant: If nobody has done a review before European morning I'll do one.
[23:55] <wgrant> rinze: Thanks, that would be great.
[23:55] <wgrant> I have a whole stack of other branches on top of this one that I'd like to get landed this cycle.