[00:04] <wgrant> lifeless: Thoughts on the timeout thing?
[00:04] <lifeless> which thing
[00:05] <wgrant> See here 50 minutes ago
[00:05] <lifeless> uhm, why is the controller destroyed?
[00:05] <lifeless> oh, paging it
[00:05] <lifeless> in
[00:05] <lifeless> ..
[00:05] <lifeless> ..
[00:05] <lifeless> ..
[00:06] <wgrant> Controller destruction and soft request timeouts are both end-request events.
[00:06] <lifeless> soft time out is checked at end of request
[00:06] <mwhudson> it's removed in the endRequest event handler right?
[00:06] <wgrant> Yep
[00:06] <lifeless> you want the controller info in the oops
[00:06] <mwhudson> woo components
[00:06] <lifeless> so no, thread local values won't help
[00:06] <lifeless> you either want the events ordered, or one event
[00:07] <StevenK> Ah, so I can't delete a team I own? WTF?
[00:07] <wgrant> Well, we don't have the controller info now, and I wanted a quick way out :)
[00:07] <wgrant> But OK
[00:07] <lifeless> wgrant: poolie put the flag stuff into the oopses for hard oopses
[00:09] <poolie> lifeless, i haven't forgotten the timeline stuff :)
[00:09] <poolie> just so you know
[00:09] <poolie> it's still within shouting distance of the top of stack
[00:09] <lifeless> poolie: thanks, I know; it was only last week we chatted
[00:11] <wgrant> Maybe I can do the soft timeout in afterCall or so instead.
[00:12] <wgrant> Unfortunately I've mostly forgotten how publication works.
[00:13] <wgrant> Bah
[00:13] <wgrant> GitHub has hung Firefox
[00:14] <lifeless> o/
[00:14] <mwhudson> clearly you should be using safari
[00:21] <wgrant> wallyworld_: Ready to talk?
[00:21] <wallyworld_> wgrant: sure, i'll start mumble
[00:38] <wgrant> In [4]: lp = Launchpad.login_anonymously('fewfw', 'dev', 'devel')
[00:38] <wgrant> In [5]: lp.access_policy_services
[00:38] <wgrant> Out[5]: <lazr.restfulclient.resource.Collection object at 0x106abcec>
[00:38] <wgrant> wallyworld_: ^^
[00:39]  * StevenK wonders why deleting a team he owns brings up "There is 1 error"
[00:39] <wgrant> wallyworld_: http://pastebin.ubuntu.com/853451/
[01:03] <wallyworld_> wgrant: i can hear you
[01:04] <wallyworld_> wgrant: i'll restart mumble
[01:06] <StevenK> Now, why can't I delete a team I just created?
[01:08] <lifeless> delete? Delete? DELETE?
[01:09] <wgrant> LPCONFIG=development utilities/create-lp-wadl-and-apidoc.py --force lib/canonical/launchpad/apidoc/
[01:10] <StevenK> lifeless: It says "There is one error" but gives no indication what that is
[01:13] <lifeless> StevenK: prod? qastating? dev?
[01:16] <StevenK> lifeless: qas
[01:16] <StevenK> https://qastaging.launchpad.net/~foobarbazquux
[01:16] <wgrant> Ah
[01:16] <wgrant> Team deletion won't work
[01:16] <wgrant> At all
[01:16] <wgrant> Because qastaging's DB is beyond all reasonably definitions of fuckedness.
[01:16] <StevenK> Right
[01:17] <StevenK> Which means person merge is utterly fucked too
[01:17] <lifeless> its being rebuilt as we speak
[01:17] <wgrant> StevenK: Deletion is merge.
[01:17] <StevenK> wgrant: I'll mark bug 934778 as untestable
[01:17] <_mup_> Bug #934778: Typo in informational message after deleting a team <docs> <merge-deactivate> <qa-needstesting> <trivial> <Launchpad itself:Fix Committed by stevenk> < https://launchpad.net/bugs/934778 >
[01:17] <StevenK> At the end of the day, it was a mechnical change anyway
[01:18] <lifeless> the robots are revolting ?
[01:18] <StevenK> sourcherry is, anyway
[01:28] <StevenK> wgrant: Are you done with wallyworld_?
[01:29] <wgrant> Not even close :(
[01:43] <wgrant> StevenK: We're done now.
[01:43] <wgrant> But I'm about to have lunch unless you need something.
[01:45] <StevenK> wgrant: Go and have lunch, we can chat about LimitedView after lunch.
[01:46] <wgrant> StevenK: Does it provide any immediate benefits?
[01:46] <wgrant> Or should we deploy now without it?
[01:47] <StevenK> It's not flagged, so if it works as intended it should remove the confusing UI
[01:47] <wgrant> Oh, has the template been modified?
[01:47] <StevenK> Not as yet
[01:47] <wgrant> Then how can it remove the confusing UI?
[01:48] <wgrant> Nothing uses LimitedView on Bug, does it?
[01:48] <StevenK> I thought the template had been fixed by sinzui
[01:48] <wgrant> Didn't you just say the template hadn't been modified?
[01:48] <wgrant> How was it tested without an adapter?
[01:49]  * StevenK was going by what wallyworld_ told him
[01:49] <wallyworld_> hmm?
[01:49] <wallyworld_> yes, the base page template supports rendering entites with limited view
[01:50] <wallyworld_> it won't render the main or side slots for example
[01:50] <wgrant> Ah
[01:50] <wallyworld_> just put in a message saying "you cannot see this"
[01:50] <wgrant> Not sure it will actually work, though.
[01:50] <wgrant> The view init will probably trip over not having View
[01:50] <wgrant> Needs testing
[01:50] <wallyworld_> works for teams, and yes, if init touches anything meeding view, you're stuffed
[01:51] <wallyworld_> need to add permission checks if that's the case
[01:51] <wallyworld_> in the init
[01:53] <StevenK> wgrant, wallyworld_: http://nowhiring.com.au/424936+job+Prime+Minister+of+Australia+ACT.aspx
[01:53] <wallyworld_> urgh, asp
[01:54] <wallyworld_> i might forward the link to krudd
[01:54] <StevenK> Hah
[01:54] <StevenK> I hear he has a bunch of free time now.
[02:16] <wallyworld_> wgrant: the top level stuff and navigation rules all work nicely
[02:26] <wgrant> wallyworld_: You have a trivial service?
[02:37] <wgrant> StevenK: Did you change the traversal check?
[02:37] <wgrant> StevenK: I can't traverse to bugs on which I should have LimitedView.
[02:38] <StevenK> wgrant: There's a traversal check? :-(
[02:40] <wallyworld_> wgrant:  yes, there's a trivial service
[02:42] <wgrant> StevenK: That's how it 404s.
[02:43] <wgrant> StevenK: You know that this is testable locally, and the view will probably need changes, right?
[02:44] <wallyworld_> wgrant: StevenK: the traversal check has already been changed to only require limitedView IIRC
[02:45] <wgrant> The launchpadlib collection check was. I don't know about the bug traversal check.
[02:47] <wallyworld_> i thought it had but could be wrong
[02:50] <StevenK> wgrant: So, I think I was led down the garden path a bit by wallyworld_
[02:50] <wallyworld_> StevenK: it all works fine for teams
[02:50] <wallyworld_> and bugs should be similar
[02:50] <StevenK> wgrant: If you point me at the traversal check, I'll look into fixing it
[02:50] <wallyworld_> if it needs fixing
[02:51] <StevenK> wallyworld_: wgrant has already stated it does
[02:51] <wallyworld_> do teams use different traversal?
[02:51] <StevenK> wgrant: As it is, r14855 is safe to deploy, but it doesn't work.
[02:51] <wallyworld_> the traversal stuff that was changed was in the base publisher
[02:51] <wallyworld_> so it should work for most things, no?
[02:52] <StevenK> [13:37] < wgrant> StevenK: I can't traverse to bugs on which I should have LimitedView.
[02:52] <wgrant> wallyworld_: Yes, it's separate.
[02:52] <StevenK> wallyworld_: ^
[02:52] <wgrant> Only two types of objects have the forbidden-equals-404 check AFAICT
[02:52] <wallyworld_> hopefully only bugs is different then
[02:53] <wgrant>         # Get out now if the user cannot view the bug. Continuing may
[02:53] <wgrant>         # reveal information about its context
[02:53] <wgrant>         if not check_permission('launchpad.View', bug):
[02:53] <wgrant>             return None
[02:53] <wgrant> Ah crap.
[02:53] <wgrant> StevenK: You are in for a world of pain.
[02:53] <wgrant> StevenK: You need to introduce a new view, basically.
[02:53] <wgrant> StevenK: On IBug
[02:53] <wgrant> Since IBug doesn't have a +index of its own -- it redirects to the default task.
[02:53] <wgrant> Which is private information.
[02:54] <StevenK> Perhaps we should introduce a NotSharedWithUserView or something?
[02:54] <wgrant> In related news, multitask bugs are hideous.
[02:56] <wgrant> Anyway, let's deploy.
[02:56]  * wgrant deploys.
[02:57] <StevenK> wgrant: Including or excluding r14855?
[02:57] <wgrant> Including.
[02:57] <wgrant> No reason to exclude, really.
[02:57] <StevenK> Or a reason to rollback
[02:58] <wgrant> Well
[02:58] <wgrant> Bug's security declarations are terrible.
[02:58] <wgrant> But I don't think it's too holy.
[02:59]  * StevenK sighs
[02:59] <StevenK> Where did my route to the DC go?
[03:00] <wgrant> lolxetel
[03:01] <wgrant> StevenK: you need to fix Bug's security declarations before you continue.
[03:02] <wgrant> We can deploy now, but you must do nothing further on this until you fix them.
[03:02] <StevenK> Which you just said were terrible.
[03:02] <wgrant> Yes
[03:02] <wgrant> They are more terrible than I expected.
[03:02] <wgrant> Not fatal, but not good.
[03:02] <StevenK> So, my current plan was to look at Curtis' bug and branch so I can unblock him
[03:02] <StevenK> But I can't reach the DC
[03:03] <StevenK> This is reminding me of when wgrant couldn't.
[03:04] <wgrant> qa-meh-itll-do
[03:04] <StevenK> qa-wcpgw
[03:05] <StevenK> Ah. I think I'm getting TTL expired
[03:05] <StevenK> Because L3 are a bunch of idiots
[03:08] <StevenK> I think v6 traffic is immune, which is nice
[03:09] <wgrant> The DC is also immune to v6, though :(
[03:12] <StevenK> Hmmm, the route has changed. I think Exetel may have noticed, since their core is now dropping everything
[03:14] <StevenK>  19.|-- 4.69.134.77                                 88.9%     9  244.9 244.9 244.9 244.9   0.0
[03:14] <StevenK> Muppets.
[03:14] <StevenK>  20.|-- 4.69.137.77                                 88.9%     9  312.1 312.1 312.1 312.1   0.0
[03:14] <StevenK>  21.|-- ???                                         100.0     8    0.0   0.0   0.0   0.0   0.0
[03:26] <StevenK> Yay, I can hit the DC again
[03:26] <StevenK> Nice how it took Exetel 30 minutes to drop their route to Telstra, since they are the cause.
[04:30] <StevenK> What the?
[04:30] <StevenK> Look at any bug reported against LP and hover over "Launchpad itself"
[04:38] <wgrant> StevenK: Mmm, delicious 2007.
[04:42] <wgrant> (2007 + bugs, but still 2007)
[04:52] <StevenK> wgrant: So, what needs to happen with the bug security adapters?
[04:52] <wgrant> StevenK: They leak tonnes of stuff that needn't be leaked.
[04:53] <wgrant> Grab https://bugs.qastaging.launchpad.net/api/devel/bugs/718213/duplicate_of?ws.accept=application/json as anonymous
[04:53] <_mup_> Bug #718213: Can't access due to content. <Internet Archive - Tech Support:New> < https://launchpad.net/bugs/718213 >
[04:53] <wgrant> It's a dupe of bug #1234, which I've made private.
[04:53] <_mup_> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts <lp-foundations> <Launchpad itself:Fix Released by debonzi> < https://launchpad.net/bugs/1234 >
[05:00] <StevenK> Lots of that JSON is redacted
[05:01] <wgrant> And lots is not.
[05:02] <StevenK> wgrant: What do you want to see disappear?
[05:02] <wgrant> Pretty much all of it.
[05:02] <wgrant> I don't have access to the bug.
[05:02] <wgrant> I don't really need to see much.
[05:02] <StevenK> I think the issue is the <allow ... in the ZCML
[05:03] <wgrant> Indeed.
[05:03] <StevenK> Most of them should drop to launchpad.View ?
[05:03] <StevenK> Which means anonymous users can't fetch them for public bugs eithwer
[05:03] <wgrant> I would suspect so.
[05:04] <wgrant> Oh?
[05:04] <StevenK> Oh, I'm wrong?
[05:04] <wgrant> launchpad.View is held by anonymous users for public bugs.
[05:04] <wgrant> I would hope.
[05:04] <wgrant> If it's not it's a bug.
[05:04] <StevenK> So, id needs to stay, as does private.
[05:05] <wgrant> Regrettably.
[05:07] <StevenK> [16:06] < Solver> Dodo announced THE INTERNET to Telstra and they accepted it
[05:07] <wgrant> Heh
[05:07] <StevenK> wgrant: ^ Cause of my DC unreachability
[05:08]  * StevenK kicks wallyworld_
[05:08] <wallyworld_> ouch
[05:08] <StevenK> That's what you get for importing ILaunchpadCelebrities into bugs.security
[05:09] <wallyworld_> did i do that?
[05:09] <StevenK> 14186.3.3   ian.boo | from zope.component import getUtility
[05:09] <StevenK>                     |
[05:09] <StevenK>                     | from lp.app.interfaces.launchpad import ILaunchpadCelebrities
[05:10] <wallyworld_> i should have used personroles
[05:10] <wallyworld_> not sure why i didn't
[05:10] <wallyworld_> moment of madness
[05:10] <StevenK> user is already an role
[05:11] <StevenK> wallyworld_: I'm putting up a small branch to fix
[05:12] <wallyworld_> ok. i thought by what you were saying you'd do it as a drive by
[05:14] <StevenK> No, I don't want to cause other issues in a branch where I'm moving 30 attributes
[05:15] <wgrant> StevenK: Be warned, there may be 10 or more tonnes of test fallout.
[05:16] <StevenK> wgrant: Yes, which is why I don't want to do any drive-bys
[05:16]  * wallyworld_ stabs unity/compiz/whatever... restart time :-(
[05:19] <StevenK> wallyworld_: https://code.launchpad.net/~stevenk/launchpad/less-celebrites-bug-security/+merge/94313
[05:20] <wallyworld_> looking
[05:21] <wallyworld_> StevenK: r=me
[05:21] <wallyworld_> thanks for fixing
[05:24] <wgrant> Bah
[05:24] <wgrant> I wish we were on postgres 9.1
[05:24] <StevenK> Tossing through ec2 just to see if there are any failures
[05:46] <wgrant> Bah
[05:46] <wgrant> BugHeatUpdater is only 300 times faster.
[05:46] <StevenK> Only
[05:47] <wgrant> Yes, only.
[05:47] <wgrant> Was hoping for more than 1000x.
[05:47] <wgrant> Must still be something wrong.
[05:47] <stub> A penchant for wishful thinking? :-)
[05:48] <wgrant> Oh, blah, the bug->task heat mirror trigger.
[05:48] <wgrant> Forgot about that.
[06:01] <nigelb> wgrant: https://twitter.com/#!/nigelbabu/status/172561507148763136 :D
[06:01] <nigelb> I hope I didn't convey that lp is only 300 times faster...
[06:01] <wgrant> Heh
[06:12] <wgrant> Oh oops.
[06:29] <nigelb> Man, "What Could Possibly Go Wrong" should be like the key phrase for LP.
[06:41] <StevenK> wgrant: Only 41 failing tests.
[07:00] <StevenK> wgrant: Right, http://pastebin.ubuntu.com/853644/ looks pretty good, and has no failing tests.
[07:01] <StevenK> Pity default_bugtask, getBugTask and userCanView had to be made public too
[07:01] <wgrant> StevenK: default_bugtask does not need to be public.
[07:01] <StevenK> The factory goes boom if it is not
[07:02] <wgrant> That's not an excuse.
[07:02] <wgrant> The factory can log in as an admin or remove the security proxy :)
[07:02] <StevenK> userCanView is the excusable.
[07:02] <StevenK> s/the //
[07:03] <wgrant> Yes.
[07:03] <StevenK> getBugTask is not, right?
[07:04] <wgrant> Unless you are extremely convincing, it is indeed not excusable.
[07:05] <wgrant> I would expect the only public attributes to be id, private, and userCanView
[07:05] <wgrant> Possibly not even private :)
[07:05] <StevenK> I'm leaving private for the time being
[07:05] <wgrant> Yeah
[07:05] <wgrant> private isn't leaking
[07:06] <wgrant> It's just dirty
[07:06] <StevenK>   File "/home/steven/launchpad/lp-branches/less-bug-leakage/lib/lp/testing/factory.py", line 1682, in makeBug
[07:06] <StevenK>     bugtask = bug.default_bugtask
[07:06] <StevenK> ForbiddenAttribute: ('default_bugtask', <Bug at 0xd21c150>)
[07:07] <wgrant> with admin_logged_in()
[07:07] <wgrant> Or rSP
[07:07] <wgrant> Probably rSP
[07:07] <wgrant> Depending on whether you're returning the task or not.
[07:08] <StevenK> No, we're not returning it
[07:08] <StevenK> Using it for date_closed and milestone only
[07:08] <wgrant> Then you can just unproxy it and nobody will care :)
[07:13] <StevenK> This branch is *tiny*
[07:13] <StevenK> +7/-9
[07:15] <G> StevenK: and you've got 2 lines for the future :P
[07:15] <StevenK> I suspect I have a lot more than that.
[07:16] <StevenK> Both wgrant and I tend to remove a lot of code.
[08:31] <wgrant> zomg
[08:31] <wgrant> BugHeatUpdater caught up
[08:32] <wgrant> For the first time in more than a year
[08:32] <wgrant> Maybe we will stop having so many oopses now.
[08:32] <StevenK> steven@liquified:~/launchpad/lp-branches/less-bug-leakage% subunit-stats < lp.log | grep Failed
[08:32] <StevenK> Failed tests:    307
[08:32] <wgrant> Uhoh
[08:32] <wgrant> Ah
[08:32] <wgrant> Not so bad
[08:33] <StevenK> Almost all of them are default_bugtask
[08:33] <wgrant> That's why I haven't preemptively euthanised you yet.
[08:33] <StevenK> Oh?
[08:33] <StevenK> Why would you want to do that?
[08:34] <wgrant> Because if they were 307 different failures, you'd want it.
[08:34] <StevenK> Haha
[08:50] <wgrant> stub: http://people.canonical.com/~wgrant/launchpad/bug-legacy-mirror.sql is my current plan for migration of bugs to the new privacy model. Lets us safely run both schemas in parallel during the migration without worrying about syncing in the app. Rather abhorrent, I know, but it's fast and temporary.
[08:51] <stub> We have too much data to migrate in a 5 minute window?
[08:52] <adeuring> good morning
[08:53] <wgrant> stub: Given the interactions with already unperformant bug search, we'd like to be able to revert to the old ways quickly if things don't perform optimally.
[08:54] <stub> If it is good enough to get past staging, can we tell if any performance issues on production are because of the new schema or because of existing issues?
[08:55] <wgrant> Heh, have you tried a bug search on staging? :)
[08:56] <stub> So we have a new feature we have no way of qaing ?
[08:57] <wgrant> Most recent risky performance tweaks have been done by deploying them with feature flags, releasing to launchpad, then beta-testers, then everyone.
[08:57] <wgrant> Because staging just isn't good enough.
[08:57] <stub> I see a fairly complex trigger, so I'm wondering if we can avoid it and the potential for bugs it brings.
[08:57] <wgrant> And for stuff like bug search, where there are thousands of different queries...
[08:57] <wgrant> Heh, yeah. There is that issue.
[08:58] <stub> Is the compatibility code more likely to cause troubles than the new work :)
[08:58] <stub> Will we be hiding use of the new schema behind a feature flag, so most users continue to use the old schema?
[08:59]  * stub can't even load bugs.staging.launchpad.net...
[08:59] <wgrant> stub: Yes, it will all be behind feature flags.
[08:59] <stub> So we must have the two models running in parallel then.
[09:00] <wgrant> Well, we basically have to. Even if we want to just cut over, we'd have to have horrifying views or hybrid appserver code to cope after the change.
[09:00] <wgrant> Because we don't have code changes at the same time.
[09:00] <stub> Populating one schema asynchonously is sucky, so I think we are stuck with a trigger like you have
[09:00] <wgrant> I figure doing it this way makes that much easier and safer.
[09:00] <wgrant> And lets us back out.
[09:00] <stub> yup
[09:00] <wgrant> The trigger is sucky, yes.
[09:01] <czajkowski> gah
[09:02] <stub> Much better :)
[09:02] <wgrant> stub: The idea is that we get the new schema running in parallel, adjust the bug search code to optionally use it, do lots of performance testing. Based on the results of that, probably implement a flattened bug+bugtask table (which I've already done some testing on, with very promising results). Once we're comfortably on the new schema, dump the old one and make the new one writable and we're in a happy place.
[09:03] <czajkowski> stub: great start to my day eh
[09:04] <stub> wgrant: Yes, this seems the sanest approach.
[09:06] <wgrant> stub: Thanks, just wanting to get your veto before I do much more :)
[09:06] <stub> czajkowski: I have your attempts in scrollback if you don't have the history :)
[09:07] <czajkowski> stub: elmo thanks.
[09:08] <wgrant> Aw
[09:08]  * czajkowski goes and makes another cuppa tea 
[09:09] <stub> wgrant: urgh... using EXECUTE to ensure the query gets planned, rather than using the static plan generated when the procedure was compiled :-(
[09:09] <wgrant> stub: I know :(
[09:09] <wgrant> I'm not sure what the actual prepared plan is.
[09:09] <wgrant> But it takes 20ms rather than 150us
[09:10] <stub> I just make elmo buy me more hardware.
[09:10] <wgrant> :)
[09:13] <wgrant> stub: The indices are partial on product IS NOT NULL and distribution IS NOT NULL, so I guess it can't use them unless it knows there aren't any nulls.
[09:14] <stub> wgrant: Adding redundant 'product is not null' clauses might help there.
[09:16] <wgrant> Indeed.
[09:16]  * wgrant tests.
[09:18] <wgrant> Indeed, that works.
[09:18] <wgrant> Even a few hundred microseconds faster.
[09:19] <wgrant> I guess it will avoid the present prod planning problems, too.
[09:21] <wgrant> Ideally I'd use conditional triggers rather than filtering in plpgsql, but that's not available until 9.0 :(
[09:24] <StevenK> Heh, wallyworld_ has landed his two step picker again
[09:24] <wgrant> Yep
[09:24] <StevenK> Shall we go for two rollbacks? :-)
[09:24] <wallyworld_> i fixed it
[09:24] <wgrant> Looked over it this morning, and there're no glaring issues this time.
[09:24] <StevenK> s/this time/yet/ ? :-P
[09:24] <wgrant> And a global potential XSS fix.
[09:24] <wgrant> Can't argue with that :)
[09:25] <StevenK> We might even deploy it tomorrow
[09:25] <wallyworld_> wgrant: btw, the launchpadlib api doesn't work with the new services stuff :-(
[09:25] <wgrant> wallyworld_: Does so. What doesn't?
[09:25] <wallyworld_> wgrant: lp.load('/services') fails
[09:25] <wgrant> There's no reason this shouldn't work, but it might take a bit of poking.
[09:25] <wgrant> wallyworld_: What error?
[09:26] <wallyworld_> invalid xml id #service_factory
[09:26] <wallyworld_> because there's no collection exported
[09:26] <wgrant> Sinister.
[09:26] <wgrant> Do you have a branch?
[09:26] <mrevell> Hello
[09:26] <wallyworld_> wgrant: just writing a test or two, give me a few minutes
[09:26] <wgrant> wallyworld_: Sure
[09:26] <wallyworld_> mrevell: g'day
[09:26] <wgrant> wallyworld_: We should be able to make lp.services.access_policies work as well.
[09:27] <wallyworld_> wgrant: hope so
[09:27] <wallyworld_> mrevell: only a few more days for you to put up with bigjools \o/
[09:29] <mrevell> wallyworld_, We have a band waiting at the air port to see him off. That and big banners with a "Never darken these shores again".
[09:29] <wallyworld_> hah
[09:29] <wallyworld_> mrevell: but now *I* need to deal with him
[09:29] <wallyworld_> no fair
[09:40] <wgrant> stub: Want to rebuild bug_fti for hopefully the last time for a while? :)
[09:40] <wgrant> stub: The new BugHeatUpdater took 1.5 iterations to do the entire backlog, so that should be it.
[09:41] <wgrant> (currently at 67% bloat)
[09:46] <wgrant> Hm
[09:46] <wgrant> I wonder if I can make update-pkgcache massively faster with SPPH.spn
[09:46] <wgrant> That would be nice.
[10:06] <wgrant> StevenK: Those 307 errors look pretty easily fixable?
[10:10] <wgrant> blink
[10:10] <wgrant> There's no SPPH index on (archive, distroseries) :(
[10:10] <StevenK> wgrant: I'm not sure, I haven't investigated. I can rSP a lot, but that doesn't fill me with happiness.
[10:10] <wgrant> StevenK: In the factory it's fine.
[10:10] <wgrant> The factory can commit any evil it wants, as long as the objects it returns are proxied.
[10:10] <StevenK> Those 307 are with the factory fixed.
[10:10] <wgrant> Ah
[10:11] <wgrant> I'll be making the factory commit a loooot of evil in coming months.
[10:11] <wgrant> But it should be very fast evil :)
[10:15] <StevenK> wgrant: Oh, and that 307 is just -m bugs
[10:15] <StevenK> I'm suspecting more fallout
[10:19] <wgrant> Should be relatively minor elsewhere.
[10:19] <wgrant> I actually expected more.
[10:19] <wgrant> Given that you're fixing buggy security declarations from 2005.
[10:20] <wallyworld_> wgrant: wip, https://code.launchpad.net/~wallyworld/launchpad/pillar-access-service-infrastructure/+merge/94338
[10:20] <wallyworld_> wgrant: i used named utilities to get the services
[10:21] <wallyworld_> so the servicefactory is very simple
[10:21] <wallyworld_> to add a new service, just define it in the zcml
[10:21] <wallyworld_> and that's it
[10:21] <wgrant> wallyworld_: Ah
[10:21] <wgrant> That's why it won't work in launchpadlib.
[10:21] <wgrant> It won't be in the WADL
[10:22] <wgrant> You should still be able to say lp.load('/services/accesspolicy'), but not lp.services.accesspolicy
[10:22] <wallyworld_> the servicefactory  attribute
[10:22] <wallyworld_> load doesn't work
[10:22] <wallyworld_> lp.load('/services') neither
[10:22] <wgrant> Hm
[10:22] <wallyworld_> undefined xml id
[10:22]  * wgrant tries.
[10:22] <wgrant> Did you actually rebuild your WADL?
[10:23] <wallyworld_> yes, several times
[10:23] <wgrant> :(
[10:23] <wallyworld_> i may have missed something
[10:23] <wallyworld_> i'm happy how the webservice side of things is working
[10:23] <wgrant> It's also possible that launchpadlib is being hilarious with WADL caching.
[10:23] <wallyworld_> maybe
[10:23] <wallyworld_> bbiab, gotta feed the dog
[10:31] <wgrant> wallyworld_: In [5]: lp.load('/services/accesspolicy')
[10:31] <wgrant> Out[5]: <access_policy_service at https://api.launchpad.dev/devel/services/accesspolicy>
[10:31] <wgrant> wfm
[10:31] <wallyworld_> wgrant: what, it worked for you?
[10:32] <wallyworld_> one thing i had to do was define a url for the service
[10:32] <wallyworld_> otherwise it would complain
[10:32] <wgrant> Indeed, it will do that.
[10:32] <wallyworld_> i guess i'll try make clean and do it again
[10:32] <wallyworld_> but i've done that already
[10:33] <wgrant> Just blow away lib/canonical/launchpad/apidoc and make build again
[10:33] <wallyworld_> wgrant: can you invoke a method?
[10:33] <wgrant> wallyworld_: No. There's a launchpadlib bug about that, IIRC>
[10:33] <wgrant> Bug #681767
[10:33] <_mup_> Bug #681767: Can't use relative URLs with launchpadlib.Launchpad - generates URI object that breaks wadllib <lp-foundations> <launchpadlib :Triaged> < https://launchpad.net/bugs/681767 >
[10:34] <wgrant> Reasonable workaround.
[10:34] <wgrant> In [14]: aps = lp.load(str(lp._root_uri) + '/services/accesspolicy')
[10:34] <wgrant> In [15]: aps.getAccessPolicies()
[10:34] <wgrant> Out[15]: u'[{"index": 0, "description": "Everyone can see this information.\\n",
[10:34] <wallyworld_> wgrant: so, you can't go lp.load('/services/accesspolicy').get('xxxx') ?
[10:34] <wgrant> etc
[10:34] <wallyworld_> ah ok
[10:35] <wallyworld_> well, i'm pleased it all works for you
[10:35] <wallyworld_> now to try for me
[10:35] <wgrant> wallyworld_: Heh
[10:35] <wallyworld_> this is good
[10:35] <wgrant> wallyworld_: So, you can probably define a generic browser:url for services.
[10:35] <wallyworld_> i'm liking what we can do with this
[10:35] <wgrant> Let me try.
[10:35] <wallyworld_> i have
[10:35] <wallyworld_> already
[10:35] <wgrant> Ah
[10:35] <wgrant> I thought you meant a specific one.
[10:35]  * wgrant actually reads the code.
[10:36] <wgrant> Ah, cool.
[10:36] <wallyworld_> wgrant: all you need to do to add a service is add a bit of zcml for it
[10:36] <wallyworld_> done
[10:36] <wallyworld_> really easy :-)
[10:36] <wgrant> Would be nice if we could get it into the WADL, but that would require being able to define custom adapters, or some runtime interface patching.
[10:37] <wallyworld_> yeah, a future branch
[10:37] <wgrant> Still, the current launchpadlib way is not too bad :)
[10:37] <wallyworld_> yes, it works
[10:37] <wallyworld_> not too fugly
[10:40] <wallyworld_> wgrant: it fails for version='devel'
[10:41] <wallyworld_> when i do version='beta' it works
[10:41] <wgrant> wallyworld_: That's what I'm using.
[10:41] <wgrant> lp = Launchpad.login_anonymously('fewfw', 'dev', version='devel')
[10:41] <wgrant> Blow away your launchpadlib cache
[10:41] <wallyworld_> In [1]: from launchpadlib.launchpad import Launchpad
[10:41] <wallyworld_> In [2]: lp = Launchpad.login_with('testing', service_root='https://api.launchpad.dev', version='devel')
[10:41] <wallyworld_> In [3]: ap = lp.load('/services/accesspolicy')
[10:41] <wallyworld_> where's the cache?
[10:41] <wgrant> ~/.launchpadlib/api.launchpad.dev/cache
[10:41] <wallyworld_> ok, didn't even know that was there
[10:42] <wgrant> Might as well dispose of ~/.launchpadlib/cache as well, if it's there
[10:42] <wgrant> I think it's deprecated.
[10:43] <wallyworld_> wgrant: yay, it was the supid cache al lalong :-(
[10:43]  * wallyworld_ add a launchpadlib test to the branch
[10:43] <wallyworld_> s/add/adds
[10:44] <wgrant> Heh
[10:44] <wallyworld_> i wasted sooo much time due to that :-(
[10:45] <wgrant> That's what caches are for :)
[10:46] <wallyworld_> but cahces need to be properly maintained :-/
[10:46] <wgrant> Pssht, details.
[10:46] <wallyworld_> sigh
[10:47]  * wallyworld_ has more unity / compiz grief
[10:52] <wgrant> Oh
[10:53] <wgrant> This just gets better and better
[10:53] <wallyworld_> wgrant:  i was offline briefly. what's "this" ?
[10:53] <wgrant> wallyworld_: update-pkgcache
[10:53] <wgrant> Unrelated :)
[10:54] <wallyworld_> ok :-)
[10:54] <wgrant> Just a 20h daily script that I want to fix.
[10:54] <wallyworld_> 20h. there's still 4 to go :-)
[10:54] <wgrant> It used to be 25h
[10:54] <wgrant> Until I fixed it a bit.
[10:54] <wgrant> But it still does about 1000x too many queries.
[10:54] <wallyworld_> 25h is ok if we slow down the rotation of the earth
[10:55] <wgrant> That's a good idea.
[10:56] <wgrant> Oh look that query is now 400 times faster
[10:56] <wgrant> sigh
[11:03]  * wgrant aims to get it down to 5 minutes or less.
[11:07] <wgrant> Ah, it's back up to 23 hours :(
[14:03] <abentley> rick_h_: Could you please review https://code.launchpad.net/~abentley/launchpad/bulk-insert/+merge/94271 ?
[14:03] <rick_h_> abentley: sure thing
[14:04] <abentley> adeuring: I'm ready to join in on the Job system revamp.  Can you bring me up to speed?
[14:05] <adeuring> abentley: i only created a basic branch:
[14:06]  * adeuring os tryingto fins it again...
[14:06] <adeuring> abentley: lp:lazr.jobrunner
[14:07] <adeuring> abentley: mumble
[14:21] <adeuring> abentley: sorry,mylaptop crashed
[14:21] <abentley> adeuring: no worries.
[14:23] <czajkowski> https://bugs.launchpad.net/launchpad/+bug/936989  could someone point me in the right direction of where I'd find the answer to this ?
[14:23] <_mup_> Bug #936989: Launchpad doesn't properly redirect if ubuntu-bug user is allready logged <apport-bug> <i386> <oneiric> <Launchpad itself:New> < https://launchpad.net/bugs/936989 >
[14:23] <czajkowski> please
[14:24] <sinzui> czajkowski, I do not know what to say. I can confirm that Lp did redirect me 15 minutes ago
[14:25] <czajkowski> sinzui: likewise, but i do know from time to time i've had glitches also
[14:25] <czajkowski> :/
[14:25] <czajkowski> not today when I try and replicate it though
[14:25] <czajkowski> sinzui: good morning btw :)
[14:26] <sinzui> is it? I do not think I have ever had a good morning. I am happy to have survived the night though
[14:27] <sinzui> czajkowski, I wonder if the user has multiple profiles. The console and launcher are selecting different profiles
[14:28] <flacoste> adeuring, deryck: are we done with bug #
[14:28] <flacoste> exec'ing bin/maas in the run script would be enough to satisfy
[14:28] <flacoste> supervise.
[14:28] <flacoste> raarh
[14:28] <flacoste> paste, i hate you
[14:28] <deryck> heh
[14:29] <czajkowski> sinzui: I'm not a great sleeper and can function on about 4hrs sleep pretty well.
[14:29] <deryck> adeuring, did you chat with bryce yesterday about it?
[14:29] <flacoste> adeuring, deryck: i meant to say: are we done with bug #829074? any news from the stakeholders?
[14:29] <_mup_> Bug #829074: Show bugs that are not known to affect "official" upstream <bugs> <escalated> <qa-ok> <Launchpad itself:Fix Released by adeuring> < https://launchpad.net/bugs/829074 >
[14:29] <adeuring> deryck,flno, i did not yet talk with bryce
[14:30] <deryck> adeuring, please try to get that done today so flacoste can close out the request completely.
[14:30] <adeuring> ok
[14:32] <sinzui> czajkowski, are you gloating or challenging me. On my 25th birthday my metabolisms slipped from 5th gear to 3rd. I need 6 hours of sleep or more.
[14:35] <flacoste> thanks adeuring
[14:35] <czajkowski> sinzui: hey I'd like more don't get me wrong. I just seem to have missed the lesson on how to sleep through a night!
[14:37] <deryck> video games and melatonin
[14:37] <deryck> czajkowski, lesson learned ^^ :)
[14:38] <czajkowski> deryck: I do my loco work at night that helps, next week I get the go ahead to go back to the gym, which should kill me and help me sleep! :)
[14:39] <sinzui> deryck, Does that combat children hoping into bed? What about fighting cats? I wake up with scars, maybe I referred a cat fight in my sleep
[14:39] <deryck> see cats, that's your problem right there.
[14:40] <deryck> and I've grown immune to kids toes in my ribs somehow. :)
[14:41] <czajkowski>  lol
[14:53] <lifeless> flacoste: did you have an opinion on the oops-on-local-404 thing ?
[14:55] <adeuring> abentley: new attempt to mumble?
[14:56] <abentley> adeuring: sure.
[14:57] <abentley> adeuring: http://pastebin.ubuntu.com/854075/
[15:01] <flacoste> lifeless: whether to show OOPS id on those?
[15:01] <lifeless> flacoste: and whether to even make an OOPS
[15:02] <lifeless> flacoste: because of linkification, its not uncommon to have bad links in-site that we don't control
[15:02] <flacoste> lifeless: right
[15:02] <flacoste> we are not doing much with those OOPS right now
[15:02] <lifeless> I've been torn for a while, I think its not really a win ATM
[15:02] <flacoste> so dropping them wouldn't have any impact
[15:02] <lifeless> can always turn it on again later
[15:02] <flacoste> exactly
[15:02] <lifeless> ok, cool
[15:13] <rick_h_> abentley: did jelmer review the other one for you or was that just a drive by?
[15:16] <abentley> rick_h_: OTP
[15:17] <czajkowski> sinzui: in the LP licience reviews, I've 2 maintained by us, both look a bit dubious , later on when you can would
[15:17] <czajkowski> you please
[15:17] <sinzui> tuxubuntu can be deactivated
[15:18]  * sinzui hopes weiqi is real
[15:19] <czajkowski> nods
[15:19] <sinzui> czajkowski, I think there is a problem with gnome-go. It is real, we should own it.
[15:20] <sinzui> czajkowski, The code import is odd, not wrong, just odd
[15:20] <czajkowski> sinzui: I dont feel so bad now for asking, I managed to do the others this morning/so far but those two just looked odd to me
[15:21] <sinzui> I happen to know the registrant is the baltix maintainer, and his branch in owned by baltix. I assume that branch is his distro version. The branch is also the upstream import.
[15:23] <sinzui> czajkowski, I see the branch has a recipe and looking at the source, it has a debian dir: http://bazaar.launchpad.net/~baltix/gnomego/trunk/files/head:/src/
[15:24] <sinzui> czajkowski, We want to set this branch as the focus of development for gnomego. I think baltic will want to create a separate branch in time and maybe an extra recipe to make upstream integrate into baltix
[15:25] <sinzui> czajkowski, visit https://code.launchpad.net/gnomego
[15:25] <czajkowski> ok
[15:26] <sinzui> czajkowski,  copy the branch URL (lp:~baltix/gnomego/trunk) then follow the link to configure code hosting
[15:26] <sinzui> Paste the link to the branch field and Update to be done
[15:27] <czajkowski> lets hope I dont break things!
[15:28] <sinzui> czajkowski, I think the second option in that form is fundementally broken (Create a new, empty branch in Launchpad and link to this series). Creating an empty branch does not really help anyone. We should remove the feature to register an empty branch
[15:29] <czajkowski> sinzui: I do the change code hosting, but owner, It picks the teams I'm on, so I select the registery ?
[15:31] <sinzui> It want's to change the owner? That is odd
[15:31] <sinzui> I would pick ~registry, but I do not think we should be changing the owner of the branch unless we are asked to
[15:32] <sinzui> That would break recipes
[15:33] <sinzui> czajkowski, maybe I am doing this the hard wary. See the " set it now" link on https://code.launchpad.net/gnomego
[15:34] <sinzui> czajkowski, This simpler for want us to paste ~baltix/gnomego/trunk into the field an Update
[15:34] <czajkowski> sinzui: ahh thats a lot easier
[15:34] <czajkowski> thanks sinzui
[15:34] <czajkowski> can I have a brain dump of sinzui and lifeless please on launchpad topics!
[15:35] <abentley> rick_h_: I thought it was a review, but it looks like technically, he didn't vote.  Anyhow, it didn't get a LOC waiver from lifeless, so it won't be going in.
[15:35] <sinzui> I think my information is ordered by iChing, broken into topics about food. I do not think many people can make sense of it.
[15:36] <czajkowski> sinzui: oh food, food I cna understand!
[16:52] <rick_h_> jcsackett: if you get a sec can you peek at https://code.launchpad.net/~rharding/launchpad/watch_jsbuild/+merge/94379 ?
[16:53] <rick_h_> jcsackett: note that it's dep on a branch that's in ec2 land atm
[16:53] <jcsackett> rick_h_: sure. talking with danhg right now about some text changes. after that i can take a look at yours.
[16:53] <rick_h_> np, ty much
[17:32] <abentley> adeuring: As of r7, you don't need virtualenv, "make develop" will set you up and "make check" or bin/python setup test will run the test suite.
[17:32] <adeuring> abentley: cool
[17:40] <jcsackett> rick_h_: i see pyinotify added to the versions; you're going to update sourcedeps with that before landing, i assume?
[17:40] <rick_h_> jcsackett: yes, should be there alreday
[17:40] <rick_h_> already*
[17:40] <jcsackett> hrm.
[17:41] <jcsackett> perhaps i didn't update today.
[17:41] <rick_h_> just did it before the MP
[17:41] <rick_h_> but I did update and make sure it came down
[17:41] <jcsackett> rick_h_: dig.
[17:44] <jcsackett> rick_h_: I'm unfamiliar with pyinotify; i see you have a method for IN_CREATE and IN_MODIFY but they both use event.mask == pyinotify.IN_MODIFY; is that correct?
[17:45] <rick_h_> jcsackett: ah, let me update that sorry.
[17:48] <jcsackett> rick_h_: no worries. lemme know when the fix goes up.
[17:49] <rick_h_> jcsackett: yea, will be a few. I actually had bigger plans there I got sidetracked and forgot about oops
[18:03] <czajkowski> nn folks
[18:39] <lifeless> morning for reals
[18:40] <rick_h_> howdy lifeless
[18:40] <lifeless> hey rick_h_
[18:48] <james_w> does anyone know where the session db sql sanitising code that LP uses lives?
[18:49] <lifeless> yes
[18:49] <james_w> ah, got it
[18:49] <lifeless> and now you do too :)
[18:49] <james_w> unfortunately it's not all that helpful
[18:50] <lifeless> its very simple
[18:50] <james_w> because I can't assume a separate db
[18:50] <lifeless> I'm sure django will have different needs
[18:50] <lifeless> can you assume a particular substring match
[18:51] <james_w> I'm not sure what a good substring would be
[18:51] <lifeless> well, whats your session table ?
[18:51] <james_w> we can assume the session table name
[18:51] <james_w> probably
[18:52] <james_w> 'django_session'
[18:53] <lifeless> seems unlikely to mask legitimate traffic, and if it does unlikely to be harmful
[18:53] <james_w> with 'session key' and 'session data'
[18:54] <james_w> just if "django_session" in query: query = "<session query>" ?
[18:54] <lifeless> thats what I'd do
[18:54] <lifeless> I mean, you can be more fancy, but will it make a real difference to you?
[18:55] <james_w> probably not
[18:55] <lifeless> if someone wants to attack the system, *and* cause oopses, *and* hide a query, they can put django_session in as user data
[18:55] <lifeless> but that wouldn't mask every query I expect
[18:56] <lifeless> you could look at what django compiles for the query and do a tighter match - e.g. 'FROM django_session'
[18:56] <james_w> the other one would be user passwords
[18:56] <james_w> which could be more annoying to have redacted
[18:57] <lifeless> you're not using openid ?
[18:57] <james_w> yes
[18:57] <james_w> but it doesn't mean that it should be ignored in a librar
[18:58] <lifeless> so, same principle will apply
[18:58] <lifeless> possibly admins will have local accounts for you
[19:11] <rick_h_> jcsackett: ok, updated https://code.launchpad.net/~rharding/launchpad/watch_jsbuild/+merge/94379
[19:11] <lifeless> rick_h_: did you consider putting your watch thing as a separate tool? It seems totally unrelated to LP itself
[19:11] <rick_h_> jcsackett: I meant to go back and implement the meta.js generation when you add a new file
[19:11] <rick_h_> lifeless: yes, except that the "knowledge" of how things need to get built isn't easy to pull out some how that I can think of
[19:12] <rick_h_> since it needs to know to regex the filename, copy over the bug/code/etc app part, and map it over to the build/js/lp/$app/xxx
[19:12] <rick_h_> lifeless: but yea, I'm hoping this and hte lpjsmin can enable the other projects to keep common good practice JS/combo load build patterns
[19:12] <lifeless> that logic seems needed for the main build part too; so presumably there is a mapper function we call, which it could use.
[19:13] <rick_h_> lifeless: yea, except currently that 'logic' is in a combo-rootdir shell script
[19:13] <lifeless> so, this duplicates it into python ?
[19:13] <rick_h_> a little bit, this requires convoy package to be avail to run and such
[19:13] <rick_h_> this ONLY takes care of the combo loader, it doesn't touch launchpad.js
[19:13]  * lifeless thinks you're building up a LOC debt rapidly :)
[19:14] <rick_h_> that's too slow since it has to be completely rebuilt
[19:14] <rick_h_> well, but the idea was that I ripped out the jsmin code, decrease maint by making JS dev faster
[19:14] <lifeless> I like the idea
[19:14] <rick_h_> so yes, this adds a new script file that's + LOC
[19:14] <rick_h_> but with the jsmin branch I've - LOC as well
[19:15] <lifeless> I suggest having a mapper function, putting the watch tool somewhere separate (e.g. convoy perhaps? they might benefit from it) and having it be trivially callable with our custom mapper
[19:15] <lifeless> I worry - a lot - when we add dev tools to the LP tree
[19:15] <lifeless> they are typically entrenched and very hard to reuse when we do that.
[19:15] <rick_h_> lifeless: understand, and thought of the callable. Do you have a locationsuggestion for that? I didn't see one in my initial looking
[19:15] <lifeless> (which existing entrenchment you're running into)
[19:16] <lifeless> rick_h_: lp.services.js.something ?
[19:16] <rick_h_> lifeless: yea, I think we're in agreement in principle for sure, just hard time implementing
[19:17] <rick_h_> would a new service dir with just an __init__.py exposing the callable be ok then?
[19:17] <lifeless> fine by me
[19:17] <rick_h_> and about the variable defs? the paths? just move those into that callable then? They're a bit buried
[19:18] <lifeless> where are they defined at the moment, and are the alterable ?
[19:18] <rick_h_> I guess I can start there, no worse off.
[19:18] <lifeless> I nearly said variable but then the world exploded
[19:18] <rick_h_> right now they're in the top of the script
[19:18] <rick_h_> so we'd still need something Make can call, but I guess that can be python -m lib.lp.services.js.run_jswatch or something
[19:19] <rick_h_> right now those build paths and such are part of all the build/makefile/buidlout process
[19:19] <rick_h_> so it just feels strange to move them down into tree
[19:20] <lifeless> rick_h_: a buildout template can be just: #!\nfrom lib.lp.services.js import path_map\nfrom convoy.buildwatch import watcher\ndef __main__():watcher(path_map)\n
[19:20] <rick_h_> lifeless: right, yea. Let me know it out and I'll see if things fall into place.
[19:20] <lifeless> make can then just call bin/jsbuildwatch or whatever the name is again
[19:20] <rick_h_> so I'm looking to add a jsbuild_watch python module that's external/reusable requiring a callback to be sent to it right?
[19:21] <rick_h_> lifeless: right, cool
[19:21] <lifeless> yeah
[19:21] <lifeless> something which you can write a tiny bit of code to use in e.g. maas, or u1, or ...
[19:21] <rick_h_> lifeless: right, that might make sense to take back to convoy. I'll check it out.
[19:22] <rick_h_> jcsackett: ok, so nvm on the review :) thx
[19:26] <jcsackett> rick_h_: fair. :-p
[19:26] <james_w> https://code.launchpad.net/~james-w/python-timeline-django/obscure-session-info/+merge/94439
[19:29] <rick_h_> james_w: I don't think we can review that one for you
[19:30] <james_w> rick_h_, that's ok thanks
[19:30] <james_w> rick_h_, I was just noticing it here because I was discussing it a little earlier in here
[19:30] <james_w> someone else on my team will do the actual review
[19:30] <james_w> sorry for not being clear
[19:30] <rick_h_> james_w: ah ok cool. Wanted to try to get my OCR hours in but no buttons there
[19:31] <james_w> :-)
[19:57] <rick_h_> lifeless: re last-mod header, what header would you send the content hash back with?
[19:57] <rick_h_> lifeless: I was noticing that I was geting 304 not-modified responses from some static files, but nothing out of the combo loader so got down this path of why/how to get the combo loader files treated the same as static files
[19:59] <rick_h_> lifeless: nvm, so you mean set the hash as the etag vs last-mod header
[20:04] <lifeless> ayup
[20:05] <lifeless> of course this means you have to honour INM as well - or just set good cache headers and put a squid in front
[20:06] <lifeless> rick_h_: actually, thats better - for *us* we never edit a file, so we want to just set cache-control: 100000 or something
[20:06] <lifeless> and expires: now+1 year
[20:06] <rick_h_> lifeless: yea, so I ran into this on an outside app I'm using convoy for
[20:06] <lifeless> (more or less, I can dig up the canonical make-it-never-expire reference fo you layer)
[20:06] <rick_h_> the trouble I was getting is that while I set expires headers way out, it would still request because it didn't have a last-mod date in the resp
[20:07] <lifeless> rick_h_: ah cool. So, LMT can be done, but IMO etag is safer
[20:07] <lifeless> up to you
[20:07] <rick_h_> I didn't try an etag header though. Trouble with that is that convoy streams the response, so getting the etag header is going to be a pita
[20:08] <lifeless> technically you can set it at the end, but I know of -no- web stacks that handle trailers correctly
[20:08] <rick_h_> lifeless: yea, thanks for the heads up. I'll have to look into it some more.
[20:08] <lifeless> no worries
[20:09] <rick_h_> lifeless: do you have 5 to do Q&A on that though? I'm wrapping my head around part of it and think it might be faster to voice vs type?
[20:09] <lifeless> sure, gimme a few and I'll ping you
[20:09] <rick_h_> ty
[20:27] <lifeless> rick_h_: ok
[20:27] <rick_h_> lifeless: tech of choice?
[20:28] <lifeless> one that works? skype? hangouts? you know, anything proprietary
[20:28] <rick_h_> hah, gotcha
[20:44] <abentley> gary_poster: adeuring and I are working on a new lazr package: lp:lazr.jobrunner.  I am having trouble getting it working in developer mode: http://pastebin.ubuntu.com/854512/  Do you have any advice?
[20:45] <gary_poster> abentley, on call, will look soon
[20:45] <abentley> gary_poster: thanks.
[20:53] <lifeless> abentley: is it lazr.runjobs or lazr.jobrunner ?
[20:54] <abentley> lifeless: Doh!
[21:00] <lifeless> abentley: I don't know if you and adeuring have seen https://dev.launchpad.net/CreatingNewProjects, but https://launchpad.net/lazr.jobrunner suggests you haven't
[21:00] <lifeless> abentley: could you run through that checklist and update the project and metadata and so forth? thanks!
[21:01] <abentley> lifeless: sure thing.
[21:02] <lifeless> abentley: (I assume buildout worked for you now ?)
[21:02] <abentley> lifeless: Yes, thanks.
[21:02] <lifeless> cool
[21:39] <lifeless> rick_h_: btw have you had a chance to play with pybars?
[21:42] <gary_poster> abentley, heh, I had just reviewed and was going to ask the same name question.  Glad it's working.
[21:43] <abentley> lifeless: btw, going with handlebars/pybars makes a lot of sense to me.
[21:44] <abentley> lifeless: esp. given that handlebars is an expected YUI 3 technology.
[22:03] <lifeless> abentley: thanks
[22:12] <lifeless> abentley: http://blog.fastmail.fm/2012/02/20/building-the-new-ajax-mail-ui-part-2-better-than-templates-building-highly-dynamic-web-pages/ - seems to me that handlebars could compile down to DOM operations just as well
[22:12] <lifeless> which would be nice
[22:12] <sinzui> wallyworld_, We should update this page with your recent experience https://dev.launchpad.net/API/ImplementingAPIs
[22:13] <lifeless> sinzui: wallyworld_: when is your standup?
[22:13] <StevenK> Now
[22:13] <sinzui> right now
[22:13] <lifeless> I would have joined yesterday but it was a trauma
[22:13] <StevenK> You're welcome to join
[22:13] <sinzui> we are in mumble in purple
[22:19] <abentley> lifeless: It could, and that could be an advantage for big loops.  Handling unescaped might be a bit of a challenge, though.
[23:12] <sinzui> wallyworld_,  here are the cluster of bugs. I think they overlap and maybe some are duplicates, Bug #590705, Bug #615244, Bug #723753, Bug #723959
[23:12] <_mup_> Bug #590705: New Build api exposed via 'beta' rather than 'devel' <api> <lp-soyuz> <soyuz-build> <Launchpad itself:Triaged> < https://launchpad.net/bugs/590705 >
[23:12] <_mup_> Bug #615244: syntax for declaring *when* an API is exported <lp-foundations> <Launchpad itself:Triaged> <lazr.restful:Triaged> < https://launchpad.net/bugs/615244 >
[23:12] <_mup_> Bug #723753: defaulting to exporting new web service methods on all web service versions makes web service mistakes dangerous <lazr.restful:Triaged> < https://launchpad.net/bugs/723753 >
[23:12] <_mup_> Bug #723959: Separate the floating "latest" version from the latest version-in-progress <lazr.restful:Incomplete> < https://launchpad.net/bugs/723959 >
[23:12] <wallyworld_> sinzui: thanks
[23:22] <wallyworld_> hmmm. none of those appear to exactly describe the issue.
[23:25]  * wallyworld_ considers filing a new bug
[23:32] <wallyworld_> bug 939910
[23:32] <_mup_> Bug #939910: Need to export entry in version "beta" but it's only needed for "devel"  <lazr.restful:Triaged> < https://launchpad.net/bugs/939910 >