[00:11] <lifeless> james_w: ah
[00:11] <lifeless> james_w: does it give you a hint of some sort?
[00:11] <lifeless> james_w: yes, -foundations
[00:11] <james_w> lifeless: well, it says the nonce was used before
[00:12] <lifeless> yes
[00:12] <lifeless> I don't know if that indicates a bug in your code, in launchpadlib, or in the lp code.
[00:13] <james_w> my code?!?
[00:13] <james_w> never!
[00:13] <lifeless> its quite possibly lp itself
[00:14] <lifeless> one user with many api clients at once isn't a common occurence today
[00:14] <wgrant> That shouldn't cause nonce reuse...
[00:14] <lifeless> without checking the implementation, who knows.
[00:15] <james_w> wgrant: do you know how the nonces are generated and stored?
[00:15] <lifeless> OAuthNonce table
[00:15] <wgrant> LP stores them in the OAuthNonce table.
[00:15] <wgrant> Yeah.
[00:15] <wgrant> I wonder who generates them.
[00:15] <lifeless> second highest oops yesterday I think
[00:15] <james_w> are they an 8 bit number and stored forever, or are we talking heat death of the universe before this should happen?
[00:15] <lifeless> not quite, bit lower:
[00:15] <lifeless> 8 /  112  RootObject:+login
[00:16] <lifeless> oauthnonce__access_token__request_timestamp__nonce__key" UNIQUE, btree (access_token, request_timestamp, nonce)
[00:16] <lifeless> the nonce itself isn't constrained to be unique.
[00:17] <wgrant> Right, the timestamp has to match.
[00:17] <wgrant> So a collision is less likely.
[00:18] <james_w> wgrant: python-oauth by the look of it
[00:18] <james_w> nonces/timestamps are only SHOULD IIRC ;-)
[00:18] <wgrant> def generate_nonce(length=8): """Generate pseudorandom number.""" return ''.join([str(random.randint(0, 9)) for i in range(length)])
[00:18] <wgrant> Yeah.
[00:19] <james_w> 10^8 space per second?
[00:20] <wgrant> Looks like it.
[00:20] <james_w> I think this is the error you get if you don't re-sign on redirect, but I don't know why these requests would have been redirected
[00:21] <wgrant> What are the requests?
[00:21] <james_w> this one was sp.getBranch(pocket="Something")
[00:22] <mwhudson> if you take n samples randomly from N options, you have about 1 - math.exp(-n*(n-1)/2.0*N) chance of getting a collision
[00:22] <wgrant> Hmm.
[00:23] <james_w> 1 - math.exp(-n*(n-1)/(2.0*N)) ?
[00:23] <mwhudson> um
[00:23] <james_w> or 1 - math.exp((-n*(n-1))/(2.0*N))
[00:24] <mwhudson> james_w: well those last two are the same, right?  but they're both better than what i said, indeed
[00:24] <thumper> lifeless: I think having our chat after lunch would be best for limiting the disruptions
[00:24] <james_w> yeah
[00:24] <james_w> bug 645640
[00:24] <_mup_> Bug #645640: API gives 401 errors on occasion <Launchpad Foundations:New> <https://launchpad.net/bugs/645640>
[00:25] <lifeless> sure
[00:25] <mwhudson> i did this math for http://bugs.python.org/issue6598 fwiw :)
[00:25] <mwhudson> how many nonces do we generate in a second?
[00:26] <james_w> mwhudson: I don't know, but 100-1000 probably
[00:27] <james_w> assuming they are per-access-token too
[00:27] <james_w> in this case I got three 401 in 2 minutes, so I don't think it's a collision
[00:27] <lifeless> RootObject:+login 204961
[00:28] <lifeless> 2-3
[00:28] <mwhudson> james_w: yes, that seems pretty unlikely
[00:28] <lifeless> unless its per-request
[00:28] <james_w> lifeless: my comment on reliability was more about tuning than large changes, so while I agree that using Launchpad's facilities makes sense, that is a fair amount of work, and doesn't buy us much in the fine-tuning department.
[00:29] <lifeless> james_w: fair enough; my main goal is to get the system 'owned' by someone with it as part of their work portfolio
[00:29] <james_w> lifeless: so I was thinking of things such as better heuristics for transient failures, better automatic categorisation of problems, automated linking to bugs
[00:29] <lifeless> james_w: you do great, but its hardly your primary thing
[00:29] <james_w> lifeless: and I'm certainly down with that
[00:29] <wgrant> lifeless: What does +login have to do with OAuth?
[00:30] <lifeless> james_w: OOPS-1725D1955
[00:31] <lifeless> grah the pageid on that is sad
[00:32] <james_w> won't load for me
[00:32] <poolie> james_w: if you only need readonly access you could be anonymous
[00:32] <poolie> and avoid the issues
[00:32] <lifeless> james_w: https://lp-oops.canonical.com/oops.py/?oopsid=1725D1955 works for me
[00:33] <james_w> poolie: this is read-write on occaision
[00:33] <lifeless> poolie: anonymous may not be what you think it is ;)
[00:33] <james_w> lifeless: does now
[00:33] <lifeless> poolie: I'm fairly sure it allocates a token on the fly
[00:33] <lifeless> poolie: which is gross in some ways
[00:33] <poolie> lifeless: i think (imbw) it's only inside the app server, not in http
[00:33] <james_w> that's probably me
[00:33] <poolie> i agree it is a bit gross
[00:34] <lifeless> poolie: its in the appserver, but thats where this problem may be too :)
[00:35] <james_w> OAuthAccessToken.sourcepackagename?
[00:36] <lifeless> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/645651 about the oops itself
[00:36] <_mup_> Bug #645651: pageids on nonce failures are a bit bogus <Launchpad Foundations:New> <https://launchpad.net/bugs/645651>
[00:36] <lifeless> james_w: no idea why thats there
[00:37] <james_w> ah, because they can be restricted in scope
[00:38] <poolie> lifeless: i think i'll keep pushing on flags today
[00:38] <lifeless> poolie: \o/
[00:38] <poolie> i meant to give it a one or two day timeslice but it feels like there's a fair momentum/inertia effect
[00:38] <poolie> iow launchpad is heavy :)
[00:38] <lifeless> yes
[00:38] <lifeless> I wouldn't stress about doing it the right way though.
[00:38] <poolie> oh btw
[00:39] <lifeless> Like, practicality of purity.
[00:39] <poolie> if i change my mind about naming something, i can just change it, right?
[00:39] <lifeless> james_w: 755156 API requests a day.
[00:39] <poolie> there are no internal api stability rules other than that the whole thing must pass it's tests
[00:39] <lifeless> poolie: yes you can but its desirable, if folk are building on something, that they be able to CP it to production.
[00:39] <poolie> (i don't mean gratuituously; i realize it may break outstanding branches etc)
[00:39] <poolie> right
[00:39] <lifeless> poolie: so do consider leaving a forwarder behind.
[00:40] <poolie> sure
[00:40] <lifeless> you odn't have to
[00:40] <poolie> some of the naming about features vs flags etc is a bit inconsistent
[00:40] <lifeless> yeah
[00:40] <poolie> that's one nice thing compared to bzrlib
[00:40] <poolie> so as of yesterday i have a working readonly anonymous view of the rules
[00:40] <lifeless> james_w: so, 100 per second or so
[00:41] <poolie> i was wondering about proposing that in parallel with adding access control
[00:41] <poolie> just to be stepwise
[00:41] <poolie> and because there's probably nothing privacy critical  at the moment
[00:41] <lifeless> poolie: separate review, sure, but I wouldn't land it solo
[00:41] <poolie> k
[00:41] <wgrant> james_w: Scope restriction doesn't actually work, unfortunately.
[00:41] <wgrant> It would be really nice if it did.
[00:41] <wgrant> What with the rather damaging APIs that are around now...
[00:41] <wgrant> Like, say, syncSource into the primary archive.
[00:43] <lifeless> james_w: oauthnonce ||      79.96 tuples/sec
[00:43] <mwhudson> wgrant: did you get those buildd-manager logs you were after?
[00:43] <wgrant> mwhudson: I didn't.
[00:44] <mwhudson> wgrant: can you tell me what to look for?
[00:46] <wgrant> mwhudson: a startBuild(http://<one of adare and ross>.buildd:8221/, firefox, 3.6.10+build1+nobinonly-0ubuntu3
[00:46] <wgrant> I think.
[00:46] <wgrant> I may have the buildd bit wrong.
[00:46] <wgrant> But it will mention adare or ross in there somewhere.
[00:47] <mwhudson> wgrant: any idea when?
[00:48] <wgrant> date_first_dispatched
[00:48] <wgrant> 2010-09-22 07:48:40.575908+00:00
[00:48] <mwhudson> ah, there we go
[00:48] <mwhudson> mwh@devpad:/srv/launchpad.net-logs/production/cesium$ grep startBuild.*adare buildd-manager.log | grep firefox
[00:48] <mwhudson> 2010-09-22 07:48:40+0000 [-] startBuild(http://adare.buildd:8221/, firefox, 3.6.10+build1+nobinonly-0ubuntu3, Release)
[00:48] <mwhudson> 2010-09-22 07:53:13+0000 [-] startBuild(http://adare.buildd:8221/, firefox, 3.6.10+build1+nobinonly-0ubuntu3, Release)
[00:48] <mwhudson> 2010-09-22 07:55:09+0000 [-] startBuild(http://adare.buildd:8221/, firefox, 3.6.10+build1+nobinonly-0ubuntu3, Release)
[00:48] <mwhudson> 2010-09-22 13:46:15+0000 [-] startBuild(http://adare.buildd:8221/, firefox, 3.6.10+build1+nobinonly-0ubuntu3, Release)
[00:48] <wgrant> What happens immediately after the first startBuild?
[00:49] <wgrant> (the 13:46 one is from when Julian retried it last night -- we presumed it was transient)
[00:49] <mwhudson> looks normal
[00:49] <wgrant> I wonder why it's retried 5 minutes later, then.
[00:49] <mwhudson> http://pastebin.ubuntu.com/498821/
[00:49] <mwhudson> 2010-09-22 07:52:19+0000 [-] <adare:http://adare.buildd:8221/> communication failed (User timeout caused connection failure.)
[00:49] <mwhudson> 2010-09-22 07:52:19+0000 [-] <adare:http://adare.buildd:8221/> failure (None)
[00:50] <wgrant> Gah.
[00:50] <wgrant> Non-virt builders *do not do that*.
[00:50] <wgrant> Ah. And I bet that retrying the build didn't reset the failure count.
[00:51] <wgrant> So it was immediately killed the next time.
[00:51] <mwhudson> actually
[00:51] <mwhudson> http://pastebin.ubuntu.com/498823/
[00:51] <mwhudson> that dispatching line at the bottom is normal?
[00:51] <wgrant> I believe so.
[00:51] <mwhudson> ah haha
[00:53] <mwhudson> wgrant: http://pastebin.ubuntu.com/498826/
[00:53] <wgrant> That's more like it.
[00:54]  * thumper goes to find lunc
[00:54] <thumper> lunch that is
[00:54] <wgrant> However, that wasn't terminal, since the builder and job failure counts are the same.
[00:54] <mwhudson> adare seems to be timing out quite a lot
[00:54] <wgrant> Hmm.
[00:54] <mwhudson> not like every build
[01:04] <mwhudson> wgrant: http://people.canonical.com/~mwh/ppc-buildd-fail.txt
[01:05] <wgrant> mwhudson: Are builders from other archs so bad?
[01:07] <mwhudson> wgrant: hard to say, it's pretty bad though
[01:09] <mwhudson> wgrant: yuck: http://pastebin.ubuntu.com/498830/
[01:10] <mwhudson> (adare and ross are the worst though)
[01:11] <mwhudson> wgrant: ppa builders, for contrast: http://pastebin.ubuntu.com/498831/
[01:15] <wgrant> Hm, quite a difference.
[01:15] <mwhudson> still seems like a whole lotta time out for one day's log
[01:38] <wgrant> adare looks reasonably dead now :/
[01:39] <wgrant> And ross just started building something that has been attempted a couple of times befor.e
[01:39] <wgrant> I wonder what's going on.
[01:52] <poolie> hi wgrant, mwhudson
[01:53] <poolie> StevenK: what happened to https://code.edge.launchpad.net/~mbp/launchpad/mbp-trivial/+merge/32173 ?
[01:53] <wgrant> Morning poolie.
[02:04] <poolie> wow, lp certainly has a big backlog of approved non-landed mps
[02:06] <wgrant> They're mostly/all from people with PQM privs, though.
[02:07] <wgrant> Hm. Half are more than a week old.
[02:08] <thumper> lifeless: ping
[02:14] <lifeless> thumper: sec
[02:14] <thumper> np
[02:21] <lifeless> thumper: skype?
[02:21] <thumper> lifeless: just a few secs
[02:23] <thumper> lifeless: yep
[02:28] <thumper> https://lp-oops.canonical.com/oops.py/?oopsid=1723XMLP310
[02:44] <wgrant> OOPS-1727EA92
[02:44] <wgrant> That same filename works fine as an attachment on launchpad.dev
[02:44] <wgrant> But not on edge.
[02:46] <wgrant> (yes, yes, I do name files strangely to try to break LP)
[02:59] <lifeless> \o/ bugtask:+index landed.
[02:59]  * lifeless dances the happy happy dance.
[02:59] <wgrant> lifeless: What did you get it down to?
[02:59] <lifeless> wgrant: what I posted to the list
[03:00] <lifeless> wgrant: just had various test fallout to fix - things I had missed subtlties of
[03:00] <wgrant> Ah, right.
[03:00] <wgrant> Yep.
[03:00] <wgrant> lifeless: At what stage did the OOPS I referenced about occur?
[03:01] <wgrant> The initial traversal, or some librarian trickery?
[03:01] <lifeless> please wait, your enquiry is important to us
[03:02] <lifeless> do doo doo, do do do-doo
[03:02] <lifeless> I bet sodium has been exposed to water again
[03:02] <wgrant> Heh.
[03:02] <wgrant> Sounds like it needs replacing.
[03:02] <lifeless> its been replaced.
[03:03] <wgrant> ...
[03:03] <lifeless> the problem is possibly the fs
[03:03] <wgrant> Well then.
[03:03] <lifeless> or similar
[03:03] <lifeless> it does not like that oops
[03:03] <lifeless> will try again ... later
[03:03] <wgrant> k
[03:03] <wgrant> Thanks for trying.
[03:16] <lifeless> thumper: mwhudson: I need your rubber stamps, again.
[03:16] <mwhudson> lifeless: otp
[03:17] <wgrant> lifeless: Where to now? 11565?
[03:17] <lifeless> https://code.edge.launchpad.net/~lifeless/launchpad/cp/+merge/36406 when you get a chance; just code-ok :)
[03:17] <lifeless> wgrant: yes
[03:17] <wgrant> Excellent.
[03:27] <lifeless> spm: if you're not flat chat, could you drop http://pastebin.com/DZcgFsA1 onto staging as a cowboy? want to see if its going to blow up tonight so I can start on it now, if needed.
[03:27] <spm> sure, gimme a bit tho, chasing logs for beuno atm
[03:27] <lifeless> ta
[03:30] <lifeless> evil: http://samy.pl/evercookie/
[03:33] <mwhudson> for some reason i feel like viewing that url with netcat
[03:35] <jcsackett> lifeless: you ain't kidding. that's horrid.
[03:35]  * jcsackett ponders.
[03:35] <jcsackett> i believe i heard about that as being by the same person who came up with the twitter xss hack.
[03:36] <lifeless> security is damn hard :)
[03:39] <jcsackett> ain't that the truth.
[03:39] <jcsackett> at least this evercookie is open; someone can develop a plugin to kill it.
[03:41] <mars> jcsackett, is that the cookie that uses the HTML5 database to store itself?
[03:42] <jcsackett> mars: yeah. and uses png cookies, and every other storage mechanism.
[03:42] <mars> heh, nasty
[03:42] <jcsackett> link was posted above by lifeless; it's a pretty freaky thing. though tech wise, it *is* sort of impressive.
[03:43] <mars> yeah, I'm not clicking that link.  I stopped clicking when the 'Gmail contacts stealing' example page was published
[03:44] <mars> although I suppose I could use a Chrome incognito browser to look at it
[03:44] <wgrant> Unless it uses Flash cookies too.
[03:44] <mars> :/
[03:44] <mars> double yuck
[03:44] <benji> the png cookies are especially beautiful
[03:45] <wgrant> Indeed.
[03:46] <wgrant> The Web really needs to just die.
[03:50] <mars> ah, here it is, the recent debacle around ad agencies starting to use these nasty techniques: http://arstechnica.com/apple/news/2010/09/rldguid-tracking-cookies-in-safari-database-form.ars
[03:52] <lifeless> mwhudson: so, can has stamp ?
[03:52] <lifeless> thumper: ping
[03:52] <thumper> lifeless: yus?
[03:52] <lifeless> please rc stsamp https://code.edge.launchpad.net/~lifeless/launchpad/cp/+merge/36406
[03:53] <mwhudson> lifeless: still otp
[03:53] <lifeless> mwhudson: sorry, thought you weren't from the netcat comment. It doesn't actually a review, only a 'review'.
[03:54] <lifeless> mars: perhaps you could ?
[03:54] <mars> looking
[03:55] <mars> lifeless, does the report give you that output right now?  Or did you construct it yourself?
[03:55] <lifeless> mars: myself from the report
[03:56] <mars> lifeless, what am I supposed to do with this?  rubber-stamp it?
[03:56] <lifeless> mars: yes, its just so that ec2land will work
[03:56] <mars> ok
[03:57] <mars> lifeless, done
[03:57] <lifeless> thanks!
[03:58] <mars> lifeless, we can add that data to the text report later as well.  I already publish most of that info in the HTML report.
[03:58] <lifeless> mars: it shouldn't go in the txt report
[03:58] <mwhudson> storing cookies in etags is an impressively evil idea
[04:00] <lifeless> what we should do though is start showing more info about the other commits
[04:02] <mars> if only we could figure out how to make the vaccines for these internet diseases spread as quickly as the infections themselves! :)
[04:03] <mars> it would make an awesome doctoral thesis topic
[04:04] <lifeless> spm: taptap :)
[04:06] <spm> still busy :-)
[04:07] <lifeless> you might want to grab the pastebin before it times out ;)
[04:10]  * beuno starts talking more loudly than lifeless
[04:10] <lifeless> beuno: you could do these things during your workday :P
[04:11] <beuno> lifeless, I remember the days when I could...
[04:11] <beuno> they where great and people didn't yell at me during a movie
[04:11] <spm> lifeless: if you'd put your paste into a WEBSCALE pastebin, like, eg sqlite backed, timeout wuolnd't be a problem. that is all.
[04:12] <mwhudson> :-)
[04:33] <mars> lifeless, poolie, here is the new feature flags fixture in action: http://pastebin.ubuntu.com/498904/
[04:39] <poolie> mars, sweet!
[04:39] <poolie> is that already in devel?
[04:39] <beuno> jdEC2
[04:39] <mars> poolie, not yet, the branch is here: lp:~mars/launchpad/add-profiling-feature-flag
[04:39] <poolie> also, i guess in non doctest code you'd use self.useFixture(FeatureFixture...)
[04:39] <mars> needs landing polish
[04:39] <beuno> irssi FAIL
[04:40] <beuno> hi everyone!
[04:40] <mars> poolie, yes, and it is very nice.  with statements also work.
[04:40] <poolie> hello beuno; i just got a survey from LAN the other day saying "where would you like to go in South America" and I thought of you :)
[04:41] <beuno> poolie, I would love to repeat our mini-sprint
[04:41] <beuno> or just skip the sprints and do all meals!
[04:41] <poolie> heh
[04:41] <poolie> i wish code branches easily showed you the submit diff, even before the mp exists
[04:41] <wgrant> I think everything should just have a WIP MP.
[04:41] <lifeless> fileabug
[04:41] <poolie> mars, so how flags work out for you?
[04:42] <poolie> wgrant, that'd be another way to do it
[04:42] <poolie> lifeless: i'm pretty sure there is already one
[04:42] <poolie> mars i think we need more systematic naming of flags
[04:42] <poolie> i don't want to sound bureaucratic here but i just think it will help when we get more of them
[04:42] <mars> poolie, I think they will work well.  It will be nice to turn the request_profiling feature on and off from the UI and also control access by scope
[04:43] <poolie> maybe yours should be something like webapp.profiling.enabled
[04:43] <mars> poolie, yes, I pondered 'services.profiling'
[04:43] <mars> or that
[04:43] <poolie> or services.profile.enabled
[04:43] <poolie> exactly
[04:43] <poolie> matching the python module name is good, i think
[04:43] <lifeless> ugh
[04:43] <mars> what does FF do?
[04:44] <lifeless> we have many terrible python names
[04:44] <poolie> FF?
[04:44] <mars> foo.bar.enabled: True ?
[04:44] <mars> firefox
[04:44] <lifeless> so I wouldn't match them.
[04:44] <lifeless> if theres a good name, use it.
[04:44] <mars> I thought about how it would look in a  UI
[04:44] <lifeless> but often a flag will be interpreted in many modules.
[04:44] <mars> Feature: request_profiling - ON
[04:44] <poolie> so for instance
[04:44] <poolie> i think 'memcache' is a poor name
[04:45] <poolie> unless it really is going to turn all of memcache on and off
[04:45] <lifeless> it turns all of memcache on and off
[04:45] <poolie> if it's controlling memcache tal stuff more specifically, we should say that
[04:45] <poolie> or vice versa
[04:45] <mars> yes, that makes sense
[04:45] <lifeless> poolie: it turns it on and off for all uses we have of memcache atm.
[04:46] <lifeless> tal and API
[04:46] <mars> yes, that too
[04:46] <mars> so the current use makes sense
[04:46] <mars> but if you ever get anything more fine-grained, then maybe some naming could make the flag's function more obvious
[04:47] <lifeless> tight
[04:47] <lifeless> bah
[04:47] <lifeless> right
[04:48] <poolie> mars that branch looks nice
[04:48] <poolie> thanks
[04:48] <mars> ok, my vision is starting to get blurry - time to sign off.  I'll land the FeatureFixture tomorrow.
[04:48] <mars> Good night!
[04:48] <poolie> you can cc me to the review if you like
[04:48] <mars> poolie, ok, will do
[04:48] <poolie> one thing, can you mention this in the servicres.features doc string?
[04:49] <mars> ok
[05:17] <lifeless> spm: so..
[05:17]  * spm should kick lifeless from the U1 channel.... :-P
[05:18] <spm> gimme 10, just doccoing what we did and taknig a bio break
[05:19] <lifeless> kk
[05:23] <mwhudson> here's something to try if you want to cry:
[05:23] <mwhudson> host 'sdasd asdas' ns4.vpweb.com
[05:23] <mwhudson> (this is the other kind of evil to what lifeless posted earlier)
[05:26] <lifeless>     Hard / Soft  Page ID
[05:26] <lifeless>      122 /  338  BugTask:+index
[05:26] <lifeless>       91 /  212  CodeImportSchedulerApplication:CodeImportSchedulerAPI
[05:26] <lifeless>       48 /   13  Distribution:+search
[05:26] <lifeless>       45 /   25  DistributionSourcePackage:+filebug
[05:27] <lifeless>       18 /   85  Distribution:+bugtarget-portlet-bugfilters-stats
[05:27] <lifeless>       13 /   47  Milestone:+index
[05:27] <lifeless>       13 /   40  Distribution:+bugs
[05:27] <lifeless>       10 /   11  POFile:+translate
[05:27] <lifeless>        9 /    8  Person:+translations
[05:27] <lifeless>        8 /   18  DistroSeries:+queue
[05:38] <wgrant> lifeless: Is that daily lpnet?
[05:38] <lifeless> yes
[05:39] <wgrant> Not bad.
[05:51] <spm> lifeless: patched and restarting ....
[05:51] <spm> fwiw. '10' in sysadmin speak is typucally out by a factor of 3 when dealing with actual time. fwiw.
[05:52] <lifeless> so you're || close to being a black hole?
[05:53] <poolie> StevenK: hi?
[05:54] <StevenK> poolie: Hi. You didn't get a mail from ec2?
[05:55] <poolie> nup
[05:56] <poolie> did you?
[05:56] <StevenK> I certainly did, the tests failed
[05:56] <StevenK> Interesting, the exact same tests failed for my branch that I submitted at roughly the same time :-(
[05:57] <stub> We are in test fix. Is the    lp.poppy.tests.test_poppy.TestPoppy.test_full_source_upload(sftp) test being looked at?
[05:58] <stub> LayerIsolationError: Test left new live threads: [<paramiko.Transport at 0x147abe50L (cipher aes128-cbc, 128 bits) (active; 0 open channel(s))>]  <-- suprious?
[05:58] <stub> spurious even?
[06:00] <lifeless> wgrant: bug 1 in the ubuntu context - 179 queries
[06:00] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:In Progress by sabdfl> <
[06:00] <poolie> bug 1 is such a good example of why we should add task deletion :)
[06:00] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:In Progress by sabdfl> <
[06:06] <mwhudson> and why _mup_ should have rate limiting
[06:10] <wgrant> lifeless: I recall it being roughly three times that...
[06:10] <wgrant> Not bad.
[06:11] <lifeless> wgrant: 179 to the point it times out ... :P
[06:11] <thumper> lifeless: got a minute?
[06:11] <lifeless> sure
[06:12] <wgrant> Ah.
[06:20]  * mwhudson goes home
[06:27] <wallyworld_> thumper: ping?
[06:27] <thumper> wallyworld_: otp
[06:28] <wallyworld_> thumper: np. just wanted to touch base. later.
[06:29] <poolie> stub:  if we're still in testfix should that be in the topic?
[06:29] <stub> Dunno. I just forced the builds (the other one crapped out due to bzr checkout issues too)
[07:09] <lifeless> stub: hey
[07:09] <lifeless> stub: bug messages and bugactivity
[07:11] <lifeless> stub: can you see any reason not to link activity to bugmessage, thus permitting a single range query to get only actions that will be shown ?
[07:12] <wgrant> Most activities are now done by AJAX, so don't have an explicit or obvious message.
[07:12] <stub> Have to be careful not to lose activity if a message is hidden. Other than that, that seems fine.
[07:12] <stub> expect wgrant is right and you will end up needing fake messages
[07:16] <wgrant> Oh good, Debian is trying to reimplement PPAs.
[07:18] <spm> what on earth for?
[07:18] <wgrant> Well, Launchpad is evil, see.
[07:18] <spm> oh. of course. silly me.
[07:19] <lifeless> stub: huh
[07:19] <lifeless> left out
[07:19] <lifeless> wgrant: well, and we don't support sid or other debian releases
[07:20] <lifeless> stub: we have lots of activity without messages: every web action, for instance.
[07:22] <wgrant> lifeless: No, but it's surely easier for them to alter the code and run their own cut-down instance than it is to write their own.
[07:22] <lifeless> wgrant: oh sure
[07:22] <lifeless> someone should point that out
[07:32] <lifeless> stub: patch # for this ?
[07:32] <stub> eg?
[07:32] <stub> eh?
[07:33] <lifeless> ALTER TABLE BugActivity ADD COLUMN bugmessage integer;
[07:34] <stub> What are we doing this for btw? Why do we want to show activity associated with a particular message?
[07:34] <lifeless> other way around
[07:34] <lifeless> consider what bug index pages render
[07:34] <lifeless> like https://bugs.edge.launchpad.net/launchpad-registry/+bug/237315
[07:34] <_mup_> Bug #237315: search for -FOO alone causes a timeout and might be better as a substring search <infrastructure> <search> <timeout> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/237315>
[07:35] <lifeless> we render a sequence of messages and actions interleaved
[07:35] <lifeless> when there are too many messages we render the first and last 40
[07:36] <lifeless> and only the activities that occur between or around those activities
[07:37] <lifeless> stub: But the page *loads* all the activities and *all* the messages (and all the mesagechunks) every time.
[07:37] <stub> And timestamps don't do that efficiently?
[07:38] <lifeless> stub: perhaps; certainly we don't do partial loads of stuff
[07:38] <lifeless> stub: I'll hold off on the patch
[07:38] <poolie> i want to write a browser test with an admin logged in; it seems a bit hard
[07:38] <poolie> just doing 'with logged_in_user' doesn't seem to make new browsers behave as that user
[07:40] <stub> It seems we are interested in the activity in particular time ranges, not activity linked to particular messages.
[07:43] <poolie> i guess the answer is, test the view, not through testbrowser?
[07:52] <lifeless> poolie: getUserBrowser(user=person)
[07:53] <lifeless> poolie: and make person with password='test'
[07:56] <poolie> even when i give it an existing member of the admin team, i get an 'unauthorized' error
[07:56] <poolie> yet i can log in to lp.dev as an admin user and see that page
[07:58] <poolie> hm, the spr tests seem to do this
[08:00] <lifeless> poolie: its the password
[08:00] <lifeless> getUserBrowser falls back to anon
[08:01] <poolie> ! ok
[08:01] <lifeless> thus my advice -  new user with password='test', add it to admins.
[08:02] <poolie> ok, i'll try that
[08:02] <poolie> https://code.edge.launchpad.net/~mbp/launchpad/flags-gui/+merge/36415 is the readonly feature rules view, btw
[08:03] <lifeless> cool
[08:06] <poolie> i'm glad you told me about the password; that could have taken a lot of difgging
[08:09] <poolie> woo
[08:09] <poolie> lifeless: so like this http://pastebin.ubuntu.com/498976/ ?
[08:15] <lifeless> poolie: its in my second (I think) perf tuesday mail - it took me a lot of digging :)
[08:15] <lifeless> poolie: yes
[08:17] <poolie> ok, so i think that code may be not-unreasonable to land as it is
[08:27] <poolie> >> # XXX jamesh 2005-11-22: Temporary fix, which Steve should undo
[08:27] <poolie> mm :)
[08:32] <spiv> poolie: hmm, 2005 XXX, great vintage that.  Lots of character, with crufty notes.
[08:32] <poolie> :)
[08:33] <poolie> drinking well now, with great long term potential
[08:33] <spiv> Recommend cellaring: in a dark, deep hole.
[08:33] <poolie> 15% bong by volume
[08:33] <spiv> Haha
[08:37] <poolie> lifeless, i'm thinking of adding a helper that just does
[08:37] <lifeless> bong.light()
[08:37] <lifeless>  ?
[08:37] <poolie> if not getFeature(x): raise FeatureDisabled
[08:37] <poolie> a little like the requireFeature() thing in bzr tests
[08:38] <lifeless> if you want; I don't see a use for it: tal doesn't have exception flow control AFAIK
[08:39] <poolie> i was thinking of putting it in view code when a thing is totally disabled
[08:39] <poolie> the page can just fail
[08:39] <poolie> for instance, i was recursively wondering if the rules view should use this
[08:39] <lifeless> I don't really understand this; it seems a big departure from the previous model
[08:40] <poolie> oh?
[08:40] <lifeless> previously you have been building a very flexible schemaless thing
[08:40] <lifeless> this seems to imply that unset or set to '' == the error condition
[08:40] <lifeless> which is the reverse of what has previously been advocated
[08:41] <poolie> ah, i'm not saying this will be for all uses
[08:41] <poolie> just for the particular case of wholesale disabling a feature, that should cause an entire view to become unavailable
[08:42] <poolie> even if people have handcrafted the url to it
[08:42] <lifeless> mmmm
[08:42] <poolie> this won't help if you just want to disable or change some controls on a page that should otherwise keep working
[08:42] <lifeless> I think a helper might be useful
[08:42] <lifeless> but you'd want to raise a 404 in traversal
[08:42] <lifeless> we wouldn't want an exception, nor oops reports of it, would we?
[08:43] <poolie> i don't know
[08:43] <poolie> istm you _might_ want to count them, but as a different category from other things
[08:43] <poolie> a bit like 404s being a special type of oops
[08:43] <lifeless> well, you could add that in
[08:43] <poolie> if lots of people are hitting this it should raise a question mark
[08:44] <poolie> if you did indeed mean to turn it off then it's ok
[08:45] <lifeless> it could be useful, though I don't think we've got any mandatory-hidden uses yet
[08:45] <lifeless> personally I'd file it under yagni
[08:47] <lifeless> no objection to it being added, but I wouldn't want a deliberate action to noise-up the already noisy oops reports.
[08:48] <adeuring> good morning
[09:01] <wgrant> Hm, so zack isn't actually entirely averse to the idea of using an LP instance.
[09:01] <mrevell> Mornin'
[09:02] <jml> mrevell, hello
[09:37] <jml> lifeless, https://lpbuildbot.canonical.com/builders/prod_lp/builds/110/steps/compile/logs/stdio
[09:39] <lifeless> jml: sigh fuckity.
[09:47] <lifeless> jml: rc rs from you to fix?
[09:47] <jml> lifeless, what's the fix?
[09:47] <lifeless>  ) as e: -> ), e:
[09:51] <lifeless> jml: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/645860
[09:51] <_mup_> Bug #645860:  buildbot is letting production breaking changes through <Launchpad Foundations:New> <https://launchpad.net/bugs/645860>
[09:52] <lifeless> jml: ping; Can I send the fix in.
[09:57] <lifeless> jml: I'm taking your name in vain.
[10:04] <stub> Gah. So the loggers are all hierarchical, with messages bubbling up. All hierarchical except for the filters which have to be explicitly attached to the logger emitting the messages rather than at a higher point in the tree.
[10:05] <lifeless> python logging sucks
[10:08] <jml> lifeless, thanks :)
[10:08] <jml> lifeless, thanks.
[10:09] <lifeless> wgrant: https://code.launchpad.net/~leonardr/launchpad/rename-grant-permissions/+merge/36363 may make you run screaming
[10:09] <wgrant> lifeless: It did.
[10:09] <wgrant> Where is all this discussion happening?
[10:09] <wgrant> It seems to keep changing.
[10:09] <wgrant> With no public rationale.
[10:10] <lifeless> wgrant: I haven't seen any discussion.
[10:10] <wgrant> And that is mildly concerning, considering how fucked everyone will be if it's wrong!
[10:10] <lifeless> So I can't answre that.
[10:10] <lifeless> Apparently leonardr hates email :)
[10:16] <jml> oh right. that reminds me.
[10:16] <lifeless> wgrant: brakes applied.
[10:17] <lifeless> jml: do you know about this desktop oauth changing thingy stuff?
[10:17] <jml> no.
[10:17] <wgrant> lifeless: I think you probably meant "Needs Information"
[10:17] <wgrant> But thanks.
[10:17] <lifeless> jml: it seems to be getting discussed, changed with the wind and so forth with no public discussion, yet its a very delicate bit of work.
[10:17] <lifeless> wgrant: no, I mean it needs fixing.
[10:17] <jml> lifeless, yes.
[10:17] <lifeless> wgrant: the fix may be conceptual :)
[10:18] <jml> lifeless, my last point of reference was the email I sent to the list, for which I am still waiting on leonardr for a reply.
[10:18] <wgrant> After seeing that MP a few hours ago, I sort of gave up and decided I'd object at the end once the whole thing was finalised, since it kept changing and nobody seemed sure of what was going on.
[10:19] <wgrant> But objecting now is good too if others agree.
[10:19] <lifeless> wgrant: objecting to the process is fine; as is pointing out problems as they come along
[10:20] <wgrant> lifeless: Well, except that it's not really my place. So I will only really complain when somebody is about to break everything.
[10:20] <jml> lifeless, I'm also concerned: I think good desktop integration is extremely important to Ubuntu + Launchpad.
[10:20] <wgrant> jml: It certainly is.
[10:20] <lifeless> wgrant: its all our places
[10:20] <wgrant> But it needs to be done properly.
[10:20] <jml> wgrant, exactly.
[10:21] <lifeless> jml: I think its important too; I will grab leonardr and gary tomorrow but perhaps you would like to do so earlier.
[10:21] <wgrant> And it's more likely to be done properly if more people know and can analyse what's going on.
[10:21] <lifeless> minimally we need ubuntu-security, ubuntu-desktop, launchpad-security [I guess I'll wear that hat, for now] involved.
[10:21] <jml> lifeless, I've emailed gary asking for a follow-up on his comments yesterday. I'm not going to be able do much else this week.
[10:21] <lifeless> jml: gotcha
[10:22]  * jml back to sprint
[10:24] <lifeless> jml: gary's comments?
[10:25] <jml> lifeless, at the team lead meeting.
[10:27] <lifeless> and sigh, there's a dubious patch landed in launchpadlib too
[10:28] <lifeless> I wonder how to help folk realise when something is high risk vs ordinary in terms of change, folk that it should be socialised with, etc.
[10:28] <jml> lifeless, partly it's a numbers game
[10:29] <lifeless> jml: I think its also partly a cultural thing
[10:31] <lifeless> jml: I nagging feeling I am having is that lp reviews are kind of like makeup.
[10:32] <lifeless> I'm positive that the team want to make it work well
[10:33] <lifeless> we need to figure out with them how to do so; and /if possible/ draw their attention to the sorts of design things that need widespread input
[10:33] <allenap> gmb: Judging from your Twitter stream, it seems like you've been having similar problems to me all week. My branches have cooked more than a few roast dinners with the heat generated from their futile ec2 runs.
[10:34] <gmb> allenap, Yeah. Different tests keep breaking; can't get them to break locally so I guess I'm pulling in bad code from devel or something. Or maybe it's the Moon.
[10:35] <lifeless> jml: wgrant: for your interest; there was discussion about some of the mechanics, but not the direction or reasoning in #launchpad-foundations
[10:36] <jml> lifeless, which IRC network is that on?
[10:36] <lifeless> freenode
[10:36] <jml> huh.
[10:36]  * wgrant didn't know that channel existed.
[10:36] <jml> me neither.
[10:37] <jml> allenap: devel's had quite a few bad landings.
[10:38] <wgrant> Unlogged channels :(
[10:38] <lifeless> gmb: what error ?
[10:38] <allenap> jml: Okay, that makes me feel better :)
[10:39] <jml> allenap: or maybe it's had only a small number, but it takes a long time to notice them and fix them in such a way that ec2 test will include the fixes.
[10:39] <jml> Perhaps ec2 test should run against stable by default.
[10:39] <gmb> lifeless, Er... I'd tell you but I don't know how to get the info out of testrepository.
[10:39] <gmb> Since it's in an old run
[10:39] <gmb> and the most recent one didn't fail.
[10:40] <allenap> jml: That's a really good idea.
[10:40] <lifeless> gmb: subunit-filter < .testrepository/$ID | subunit2pyunit
[10:40] <gmb> lifeless, Ta.
[10:40] <jml> allenap: see https://bugs.edge.launchpad.net/launchpad-foundations/+bug/419689
[10:40] <_mup_> Bug #419689: Test failures in devel break ec2test runs <build-infrastructure> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/419689>
[10:40] <gmb> lifeless, It was a Windmill test: lp.code.windmill.tests.test_branchmergeproposal_review.TestReviewCommenting.test_merge_proposal_reviewing
[10:41] <lifeless> gmb: or for sex; tribunal .testrepository/$ID
[10:41] <lifeless> gmb: windmill errors are nearly always noise AFAICT - they show up when something else is wrong and go away when it isn't.
[10:41] <wgrant> Running against stable would make it easier for devel to break in the first place.
[10:41] <lifeless> gmb: from ec2 I mean.
[10:41] <lifeless> gmb: I've never had a windmill test pass locally.
[10:41] <lifeless> gmb: I just ignore them completely.
[10:42] <gmb> lifeless, Heh. This one did, oddly. Anyway, we'll see what happens with this ec2 run.
[10:42] <lifeless> good luck luke, may the force be with you
[10:43] <gmb> :)
[10:49] <lifeless> adeuring: regarding the librarian OOPS ID change
[10:49] <lifeless> adeuring: could we just delete that template altogether ?
[10:49] <lifeless> adeuring: and stop special casing it?
[10:49] <adeuring> lifeless: yeah, I wondered too if we really needed it. but...
[10:49] <adeuring> there might be one reason:
[10:49] <lifeless> adeuring: if you'd like to delete it, +1 from me :)
[10:50] <adeuring> lifeless: well, these errors involve another machine, the librarian server, so they can occur due to reasons like hardware failures, network problems etc
[10:51] <lifeless> adeuring: so do all our requests.
[10:51] <lifeless> adeuring: (the database server is another machine ...)
[10:51] <adeuring> well, yes, but there one more machine involved that usually
[10:51] <lifeless> true, but its not a unique thing
[10:51] <lifeless> its just more of the same
[10:51] <lifeless> global searches use google
[10:52] <lifeless> gpg key checking uses the keyserver
[10:52] <adeuring> hrmm, yeah... ok, I delete it. Though I'll be missing the "feng shui in the server room" message ;)
[10:53] <lifeless> cool!
[10:53] <adeuring> lifeless: what's the "timeline" for the token based access to the librarin?
[10:53] <lifeless> adeuring: mthaddon has the keys now, so it should be up for QA soon.
[10:54] <adeuring> cool
[10:56] <adeuring> I am still bothered by lines 148..150 in l/c/l/browser/librarain.py, where we return a 503 error without doing any logging, but if we get rid of that code soon anyway, there is no need to touch it now
[10:56] <lifeless> \o/
[10:58] <wgrant> That's why I didn't fix it.
[11:07] <wgrant> Does anyone know why launchpad-dependencies depends on ubuntu-keyring?
[11:07] <lifeless> it will be the same thing
[11:07] <lifeless> at a guess.
[11:07] <lifeless> launchpadlib had a patch land today to use gnome-keyring
[11:08] <wgrant> ubuntu-keyring is the Ubuntu archive keys.
[11:08] <lifeless> oh blah, of course.
[11:08] <lifeless> uhm, dunno.
[11:15] <adeuring> lifeless: want to review this branch: https://code.edge.launchpad.net/~adeuring/launchpad/no-feng-shui-in-the-server-room/+merge/36427 ?
[12:03] <deryck> Morning, all.
[12:13] <deryck> The level of failures from ec2 and buildbot lately is driving me insane.
[12:13] <deryck> ec2/land should become ec2/land-if-you-are-lucky
[12:17] <jml> deryck, tbh, it feels this bad for me all the time
[12:18] <deryck> maybe I've just been more productive lately, and I'm only now reaching jml levels to notice it. :)
[12:19] <jml> perhaps. :)
[14:01] <deryck> adeuring, hi.  I noticed you started on bug 594247.  Can we consider the librarian OOPS issues fixed now?  At least, all we can do for now?
[14:01] <_mup_> Bug #594247: searchTasks with structural_subscriber times out regularly <dhrb> <overlyprecise> <timeout> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/594247>
[14:02] <adeuring> deryck: yes. it is still unclear to me why I could not find as many OOPS reports as I would have expected, but looking longer at this without a better clue is pointless.
[14:03] <adeuring> and if we have a similar situation again, we should either see the OOPS number or we should get another error due to a missing OOPS ID
[14:03] <deryck> adeuring, ok, cool.  I agree.  For some reason, I thought there was another bug open on this.
[14:12] <gmb> Hooray for throwing things at EC2 until they stick.
[14:26] <mars> gmb, ?
[14:26] <gmb> mars, Windmill failed in EC2, didn't fail locally; I resubmitted.
[14:27] <mars> gmb, an intermittent failure?
[14:27] <mars> could you send me the log?
[14:29] <gmb> mars, Sent.
[14:29] <mars> thanks
[15:00] <dobey> hrmm, on bugs for projects, is it not possible to target a bug only to a release other than trunk? i notice that if i target to trunk, it changes to say "status tracked in trunk", but if I only target the bug task to a different series, then it still has the normal bug task, as well as the series task
[15:02] <cr3> can someone help me understand the difference in testing between layers and fixtures?
[15:12] <sinzui> bac: I think you can say this is fixed on edge now: https://bugs.edge.launchpad.net/launchpad-registry/+bug/252889
[15:13] <_mup_> Bug #252889: Project attributes should be altered from a link next to assertions about them <Launchpad Registry:Triaged> <https://launchpad.net/bugs/252889>
[15:16] <mars> cr3, layers are from the Zope world.  Each layer has it's own setup and teardown, and that is run once before all the tests in that layer are run, and tearDown after.  A fixture, on the other hand, is set up and torn down for each test that makes use of it.
[15:18] <mars> cr3, our layers are in a hierarchy, so to write a pagetest you must also set up a full librarian service, a full database, a full component registry - they are not composed easily.  Fixtures can be easily composed: you only .useFixture() what you need.
[15:18] <bac> sinzui: i'll have a look
[15:20] <sinzui> bac: I think that since you removed the block on the progress bar, the links to configure an app are on the page. I think we will be ready to remove the "Uses launchpad for" chunk next week
[15:22] <cr3> mars: all clear now, thanks!
[15:39] <sinzui> benji, can you point me to a file or test that shows how to export an error over the api?
[15:39] <benji> sinzui: sure, one sec
[15:40] <benji> sinzui: lib/lp/registry/model/product.py:456
[15:40] <sinzui> thank
[15:40] <sinzui> s
[15:40] <benji> np
[15:45] <wgrant> Erm.
[15:45] <wgrant> There are two methods now?
[15:45] <wgrant> What happened to annotating exception classes with webservice_error?
[15:53] <benji> wgrant: this mechanism is for individual exceptions (not classes); for example if you're going to raise a KeyError because some key passed in was not found
[15:54] <wgrant> Hmmmm.
[16:23] <cr3> when defining a database schema, there's sometimes not a meaningful difference between a cell containing none or empty string (''). so, what's the preferred approach to keeping the schema and application layer code sane?
[16:26] <cr3> hm, I'll also as in #postgresql, I've been wondering for a while what are the implications to consider
[16:26] <cr3> s/as/ask/
[16:35] <cr3> I should have a look at the launchpad schema and see if there's ever a situation where a text or varchar column can be null...
[16:37] <cr3> on an unrelated note, is there an unwritten rule about when to use which quotes, ' or "?
[17:31] <mars> gary_poster, should lib/canonical/launchpad/doc/profiling.txt be moved to lp.services.profile/doc?  Or is there a better location?
[17:33] <gary_poster> mars, I decided not to make that change for my own branch--that was where it was when I found it.  But yes, before I knew that file existed, I was putting documentation in lp/services...
[17:33] <gary_poster> So if your branch is small enough to include the move, and you want to, go for it AFAI am concerned.
[17:34] <mars> ok, thanks
[17:34] <gary_poster> np
[19:22] <lifeless> morning
[19:26] <deryck> morning, lifeless.  Care to review a small branch for me?
[19:26] <lifeless> sure
[19:26] <deryck> lifeless, thanks!  https://code.edge.launchpad.net/~deryck/launchpad/fewer-milestone-queries-bugtask-index/+merge/36458
[19:27] <deryck> lifeless, I don't think this will make significant difference yet, but still think it's worth doing.
[19:28] <lifeless> every bit helps
[19:29] <lifeless> did you see that activites is 2.5 seconds alone, for bug 1
[19:29] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:In Progress by sabdfl> <
[19:29] <deryck> lifeless, I didn't.  But I knew from your bug mail that activities and comments were the next big two.
[19:31] <deryck> rockstar, hi.  Is the yui in lazr-js the latest?  If I try to bug fix in this, will my deploying this to lp be delayed by yui version upgrade on lp?
[19:32] <rockstar> deryck, the yui in lazr-js is indeed the newest.  The only real thing blocking the update of lazr-js is the thing I raised on the mailing list last week (python dependencies)
[19:32] <deryck> rockstar, ok, so build issues not library compatibility?
[19:33] <rockstar> deryck, yeah.
[19:33] <deryck> ok, thanks
[19:33] <lifeless> deryck: approved; coupla tiny tweaks you can make if you feel like it
[19:33] <rockstar> deryck, in the first branch I tried it on, I needed to rename all yui- classes to yui3-, but that's it (as I remember)
[19:33] <deryck> lifeless, great, thanks!
[19:34] <deryck> rockstar, gmb has to get the widget in lp very soon.  And I'd like to see this bug fix I'm about to put up in lp, too.
[19:34] <deryck> wizard widget, rather
[19:34] <rockstar> deryck, yeah, I saw he just landed it.  I will be working on this tonight in fact.
[19:35] <deryck> ah, cool.
[19:35] <rockstar> deryck, I also have a hard dependency on a new yui.
[19:35] <deryck> ah, ok, so this should move forward then. ;)
[19:36] <rockstar> deryck, ideally, we aren't tied to lazr-js to upgrade yui.  Unfortunately, I don't think that will happen.
[19:40] <deryck> rockstar, there isn't a YUI wrapper around substring search is there?  i.e. prettier than foo.indexOf('some string') > -1 ?
[19:41] <rockstar> deryck, no, but feel free to write one.  I think it'd be beneficial to all.
[19:42] <deryck> ok, I could do that.  Not sure I'll do it today to be honest.
[19:43] <deryck> The lazr-js build step makes me feel less inclined to be opportunistic like this.
[19:55] <rockstar> abentley, what you do know about BranchWithSortKeys view?
[19:55] <abentley> rockstar, Sorry, no idea.
[19:56] <rockstar> abentley, from the comments, it appears to be a hack for when we used SQLObject, and was intended to be removed when we switched to Storm.
[19:56] <rockstar> abentley, I'm going to delete it and see what blows up.
[19:56] <rockstar> (It's blocking my merge queue db patch currently)
[20:04] <dobey> deryck: is it impossible to target a bug to only affect a series other than trunk?
[20:04] <deryck> dobey, I believe the series has to be the active development branch.
[20:04] <deryck> or development focus, I think we call it.
[20:06] <dobey> deryck: so there has to always be a bug target for the development focus, even if it doesn't actually affect it?
[20:06] <abentley> lifeless, have you come to any conclusions about that security stuff?
[20:07] <cr3> lifeless: hi there, I'd appreciate your advice on writing unit tests: should helper methods like makePerson which do not strictly related to unit testing be defined in a factory, whereas other methods like assertFoo which relate more to unit testing be defined in a TestCase derived class?
[20:08] <deryck> dobey, sorry, I don't follow what you mean there.  The idea is that you can only nominate bugs for an active series.  Not saying this is ideal, but that's the way it is currently.
[20:08] <lifeless> abentley: no sorry; I've been mainly head down on just performance the last week
[20:08] <lifeless> abentley: I'll revisit the mail in detail today
[20:08] <abentley> lifeless, cool.
[20:09] <dobey> deryck: i mean, if i click "Target to release" and select only series other than trunk (or i guess the development focus, as it seems), i would expect it to only be tracked in those series
[20:09] <lifeless> cr3: http://rbtcollins.wordpress.com/2010/05/10/maintainable-pyunit-test-suites/ http://rbtcollins.wordpress.com/2010/09/18/maintainable-pyunit-test-suites-fixtures/
[20:09] <lifeless> cr3: (that is, things like factory are great, putting helpers on subclasses of TestCase isn't great)
[20:10] <lifeless> cr3: but the urls are much less pithy
[20:11] <cr3> lifeless: thanks!
[20:11] <dobey> deryck: is that not currently possible?
[20:12] <dobey> deryck: or should i find a bug to point you at, which shows the issue i'm trying to find a solution to?
[20:12] <deryck> dobey, sorry, I think I'm confused and thinking of another constraint.  If you click "target to release" and you select any series on that page, it should only be linked to that series.
[20:12] <deryck> dobey, and yes, showing the issue might help me understand better
[20:13] <deryck> fwiw, I was thinking of the conjoined master condition where a conjoined bugtask is created when the series is the development focus.
[20:14] <dobey> deryck: https://bugs.edge.launchpad.net/ubuntuone-client/+bug/645519
[20:14] <_mup_> Bug #645519: DBus delete_share doesn't work for shares made by the user to others <foundations+> <u1-maverick> <Ubuntu One Client:In Progress by verterok> <Ubuntu One Client stable-1-4:In Progress by verterok> <ubuntuone-client (Ubuntu):Confirmed for ubuntuone-ops+> <https://launchpad.net/bugs/645519>
[20:16] <dobey> deryck: see how it shows status for both the project and stable-1-4? if i target to 'trunk' also, then it will show 'tracked in Trunk' instead of status there. but if i don't target to trunk, it will always show status like that
[20:17] <deryck> dobey, ok, so I was thinking of the right thing.  That's a conjoined bug task, where the status is only tracked in the series, not the main project bug task.  The series has to be the development focus to get that joined bug task.
[20:22] <dobey> deryck: ok, so there's no way to do what i want, basically?
[20:23] <deryck> dobey, if what you want is to have the status only tracked in the series for any series you target to, then no.
[20:24] <deryck> I'm not sure of the historical reasons why this choice was made, but I do think there is a bug asking for conjoined tasks on any series.
[20:28] <dobey> hrmm, i'm having trouble finding such bug filed against malone
[20:28] <dobey> should i file a new bug?
[20:28] <deryck> dobey, sure, file a new one, and I'll dupe if I find one.
[20:29] <deryck> dobey, I doubt we'll work on this, though.  Not anytime soon.  But having a bug to track it would be nice.
[20:29] <dobey> :(
[20:30] <deryck> Sorry.  Just too much needs doing to even get to that.
[20:30] <lifeless> I suspect we need to gather the 'rules' for the current implementation and go back to ground zero :)
[20:30] <deryck> heh
[20:30] <lifeless> eventually
[20:31] <deryck> yeah, that's partly why I say we won't work on it, too.  It's a largish design decision that I don't want to revisit with everything else we're active on.
[20:31] <lifeless> completely agreed
[20:32] <deryck> rockstar, I've got a lovely 4 line lazr-js branch.  Care to review it?
[20:33] <dobey> https://bugs.edge.launchpad.net/malone/+bug/646277
[20:33] <_mup_> Bug #646277: Targetting to series should result in conjoined bug task <Launchpad Bugs:New> <https://launchpad.net/bugs/646277>
[20:38] <deryck> I don't find a dupe either.  And I searched mpt's reported bugs. :-)
[20:39] <lifeless> hah
[20:39] <dobey> heh
[20:39] <dobey> now to figure why bzrlib is deciding to lie to me in the form of an Exception
[20:56] <deryck> rockstar, you still around?
[20:56] <rockstar> deryck, yup.
[20:56] <rockstar> (On the phone)
[20:56] <deryck> ah
[20:57] <deryck> rockstar, I'm EOD'ing soon.  You care to review lazr-js offline for me?  https://code.edge.launchpad.net/~deryck/lazr-js/stop-all-those-null-choice-edit-icons/+merge/36494
[20:57] <rockstar> deryck, sure.
[20:57] <deryck> thanks.
[20:57] <deryck> rockstar, if you make me write a test, I will.  But in this case, I think it's really silly.
[21:03] <rockstar> lifeless, around?
[21:03] <lifeless> hi
[21:03] <jml> ra ra ra
[21:03] <jml> still hacking in worcestershire
[21:04] <lifeless> garh, more 2.6 I missed
[21:04] <lifeless> jml: I'm going to use your name again :)
[21:04] <jml> lifeless, only if you review my incremental failure patch in testr.
[21:05] <jml> lifeless, https://code.edge.launchpad.net/~jml/testrepository/show-failures-incrementally-613152/+merge/31765
[21:05] <lifeless> jml: I can leave prod broken if you'd prefer ;)
[21:05] <lifeless> jml: its on my list, I'm keen to have it.
[21:05] <rockstar> jml, do you know anything about BranchWithSortKeys.  It seems to pre-date my time on Launchpad.
[21:05] <jml> lifeless, cool. rs=jml
[21:05] <jml> hah
[21:05] <jml> rockstar, thumper knows all about it.
[21:05] <jml> rockstar, I never really understood the need for it.
[21:05] <rockstar> jml, dammit. thumper is unavailable today.
[21:05] <jml> rockstar, it seemed to be some crappy performance hack afaict.
[21:05] <jml> rockstar, a cunning trick.
[21:06] <rockstar> jml, yeah, the comments indicate that it could go away when we moved to Storm.
[21:06]  * rockstar remembers us moving to storm a very long time ago.
[21:06] <lifeless> rockstar: hi?
[21:06] <jml> rockstar, I can search my mail for clues
[21:06]  * bigjools waves
[21:07] <rockstar> lifeless, so, I pinged you, but I'm not sure you're the best to help.
[21:07] <rockstar> lifeless, basically, I dropped a pile of columns from the DB, but I can't generate newsampledata because the old sampledata is now all screwed...
[21:08] <rockstar> ...and I REA-HE-LLY don't want to edit current.sql by hand if I don't have to.
[21:08] <lifeless> rockstar: ok, so the easiest way is probably: rebuild with db-stable's schema., apply your patch, and output the sampledata
[21:08] <rockstar> lifeless, ah, 'tis a good idea.
[21:08] <jml> rockstar, seen https://bugs.launchpad.net/bugs/154016 ?
[21:09] <rockstar> jml, I get a nice fancy 403 there...
[21:09] <jml> rockstar, looks like mwhudson also knows about it.
[21:09] <jml> me too!
[21:09] <jml> lifeless, do you have duck privs?
[21:09] <rockstar> jml, yeah, he was the next person I was going to harass.
[21:10] <rockstar> jml, basically, I've decided I'm going to kill it and see what breaks.
[21:10] <rockstar> ...Although that might make lifeless cry.
[21:10] <jml> rockstar, I've found a patch of his from 2007-10-16
[21:10] <rockstar> jml, holy crap. Data mining FTW!
[21:10] <jml> rockstar, lifeless (and I, for that matter) generally approve of trying stuff
[21:10] <rockstar> jml, yeah, but if it really ends up killing performance, lifeless will hit a child.
[21:11] <jml> rockstar, kiwi kids are tough. it's a rugby thing.
[21:19] <thumper> rockstar: it had to do with sql object not allowing sorting by columns that weren't returned
[21:19] <thumper> rockstar: yes Storm can and it should be fixed
[21:19]  * thumper isn't here
[21:20] <rockstar> thumper, okay.  I'm killing the view.
[21:20] <thumper> rockstar: good
[21:20] <rockstar> (The merge queue patch fights with it)
[21:24] <mars> lifeless, something to make your life a bit easier: a branch that checks for Python 2.5 compatibility when you run 'make lint': https://code.edge.launchpad.net/~mars/launchpad/add-py25-lint
[21:25] <lifeless> mars: tie it into make check to bb will enforce it and I'll be happy ;)
[21:25] <mars> lifeless, there is also a merge proposal for it.  I think it is floating around somewhere in the Launchpad system ether.  I'm sure it will show up somewhere.
[21:25] <lifeless> s/to/so/
[21:27] <mars> there it is: https://code.edge.launchpad.net/~mars/launchpad/add-py25-lint/+merge/36502
[21:30] <lifeless> mars: oh, I see
[21:30] <lifeless> mars: we don't have py2.5 on the lucod builders do we?
[21:31] <mars> I don't believe so
[21:55] <rockstar> Oh crap.  Did we generate sampledata on pgsql 8.3 again?
[22:01] <wallyworld> morning
[22:27] <rockstar> Wow.  Skype crapped itself at the end of that call.
[23:49] <mwhudson> has anyone tried local codebrowse recently?


[05:02] <Varth> Hey all, I'm having an issue with a Scarlett 6i6 on Ubuntu Studio 15.10. I used the Scarlett MixControl WIndows application to set input 2 to high-impedance/instrument mode; however, when I boot back  into Ubuntu Studio, input resets back to line level, indicated by the instrument light on the front panel switching off. This happens as soon as I connect the interface, before I even start JACK. Does anyone know what would be causi
[05:02] <Varth> ng this? Thanks in advance!
[14:22] <Arkomus> hi all
[16:12] <studio-user_pipo> hi
[23:31] <ubuntourist> System Settings -> Language Support crashes... Any thoughts?
[23:45] <ubuntourist> Rebooting after installs... BRB


[02:49] <anjilslaire> hey, its snowing outside, lol
[02:55] <bkerensa> :D
[21:03] <bkerensa> valorie: Ubuntu Oregon got denied approval
[21:03] <bkerensa> =/
[21:08] <Salt> srsly?
[21:09] <Salt> i wonder if we can re-apply to canonical as ubuntu-pnw, it makes WAY more sense v_v
[21:10] <bkerensa> Probably not
[21:10] <bkerensa> the funny thing is they said Ubuntu Oregon doesnt have enough history
[21:10] <bkerensa> and our LoCo existed months before any of the existing approved U.S. LoCo Teams
[21:11] <bkerensa> they said we need to show more I guess in documentation yet we do our team reports and they approved a LoCo before us that does document at all
[21:24] <Salt> that sucks
[21:25] <Salt> but yeah, here isn't the place for me to rant about canonical
[22:47] <valorie> damn it, bkerensa
[22:47] <valorie> that sucks
[22:47] <bkerensa> yeah
[22:47] <bkerensa> I don't understand it
[22:47] <valorie> sec
[22:52] <valorie> gosh, weather tomorrow is supposed to get seriously winter
[22:53] <valorie> bobby went to buy extra gasoline for the generator
[22:54] <valorie> canonical isn't the problem
[22:54] <valorie> the CC is the one doing the approving
[22:55] <bkerensa> yeah
[22:55] <bkerensa> well LoCo Council
[22:55] <bkerensa> and I pointed out that they approved a loco before us that had no documentation at all
[22:55] <bkerensa> and then they said they couldnt approve us due to lack of history
[22:55] <bkerensa> to me thats just bizarre
[22:56] <bkerensa> and unfortunately there is no way I can appeal to Community Council and even if I could I think they would just back the LoCo Council
[22:56] <bkerensa> There should be clear expectations published in a Wiki that they use in voting and they should use that for all loco's
[22:57] <bkerensa> Transparency and Fairness imho
[23:19] <valorie> just try again in a few months
[23:20] <valorie> you'll get it, 'cause you rock
[23:20]  * valorie goes off to visit dad early today
[23:20] <valorie> weather seems threatening