[00:00]  * cjwatson looks at the whole of r13734
[00:01] <cjwatson> In that revision, it had one caller, which was always copying from series.previous_series to series
[00:01] <cjwatson> I'm right in my presumption that series.previous_series is always in the same distribution, aren't I?
[00:01] <wgrant> Right
[00:01] <wgrant> Yes
[00:01] <lifeless> well
[00:01] <lifeless> we hope so
[00:02] <cjwatson> I did check it was true for Ubuntu
[00:02] <wgrant> The code ensures it's always true
[00:02] <wgrant> The DB does not
[00:02] <cjwatson> So I think this was essentially an attempt at generalising to derived distributions
[00:02] <cjwatson> But that actually what we have now in PackageCopier does a better job
[00:02] <cjwatson> And the publisher code doesn't care
[00:03] <wgrant> Yep
[00:03] <wgrant> r=me
[00:03] <wgrant> We really need to merge the uploader and copier eventually...
[00:03] <cjwatson> Yeah, it's a pretty ugly separation
[00:04] <cjwatson> They're kind of converging by iterative generalisation
[00:04] <wgrant> And it's only getting uglier
[00:04] <wgrant> Yeah
[00:04] <cjwatson> But stuff like that duplicated policy code is really hard to fix in the current layout
[00:04] <wgrant> And there are subtle differences.
[00:05] <wgrant> Largely unavoidable in the current layout, as you say
[00:05] <cjwatson> Different ancestry calculation between them
[00:05] <cjwatson> And within the uploader, come to that, but that's a different matter
[00:05] <wgrant> Yes...
[00:06] <cjwatson> cf. my comment in check_copy_permissions :-)
[00:06] <wgrant> really we want to rework PackageUpload+PackageCopyJob to work with just a "bunch of packages"
[00:06] <wgrant> Then copies and uploads can use the same infrastructure, just from different sources
[00:06] <wgrant> That would also probably necessitate making custom uploads not horrible
[00:06] <wgrant> Or at least less horrible
[00:07] <cjwatson> They could do with having something that resembles a database representation
[00:07] <wgrant> Myes.
[00:07] <cjwatson> Rather than just being bolted onto the side of PackageUpload and forgotten about
[00:07] <lifeless> cjwatson: long tradition of that :)
[00:08] <lifeless> cjwatson: when schema changes were impracticle
[00:08] <cjwatson> Mm
[00:08] <cjwatson> At least we don't have sourceless custom uploads any more :)
[00:08] <wgrant> Indeed
[00:11] <cjwatson> Right, thanks, I've sent that off to EC2.  I'll QA in the morning if it's got that far
[00:11] <wgrant> " 1 → 75 of 296 results "
[00:11] <wgrant> !
[00:11] <wgrant> cjwatson: Great
[00:37] <StevenK> wgrant: Criticals?
[00:38] <wgrant> StevenK: Yeah
[00:38] <wgrant> In launchpad, though, not launchpad-project.
[00:38] <StevenK> Yeah
[00:39] <StevenK> wgrant: Right, I can see the 35 BMPs
[00:40] <StevenK> Well, my query doesn't return the BMP ids, it returns the duplicated merge_diffs, but the 35 is the important bit.
[00:40] <wgrant> Is it actually 35?
[00:40] <wgrant> Right
[00:40] <StevenK> SELECT merge_diff FROM branchmergeproposal WHERE merge_diff IS NOT NULL GROUP BY merge_diff HAVING COUNT(*) > 1;
[00:40] <wgrant> Right, exactly.
[00:40] <StevenK> Incredibly simple
[00:41] <StevenK> wgrant: So I'm not sure what we should do, though
[00:41] <wgrant> StevenK: Delete 35 MP diffs :)
[00:42] <StevenK> wgrant: How will that help? There are two BMPs with the same merge_diff
[00:42] <wgrant> Um, yeah, maybe I'm misremembering
[00:42] <wgrant> Do we have a bug about this?
[00:42] <StevenK> I do not think so
[00:42] <StevenK> But I haven't gone diffing
[00:43] <StevenK> Er, nice slip. digging
[00:44] <wgrant> Ah
[00:44] <wgrant> So I guess we want to duplicate the previewdiffs
[00:45] <StevenK> How do we do that in 2.5 seconds? :-)
[00:47] <wgrant> There's only 35 records...
[00:48] <StevenK> wgrant: Sure, but I'm not sure how to pull out only one BMP, duplicate its previewdiff and then set it back.
[00:50] <wgrant> StevenK: We'd probably want to duplicate the LibraryFileAlias, Diff, and PreviewDiff, then set BranchMergeProposal.merge_diff
[00:51] <StevenK> LFA is involved?
[00:52] <StevenK> wgrant: I can't see how LFA is involved
[00:52] <wgrant> StevenK: diff.diff_text is an LFA
[00:52] <StevenK> Ah
[00:52] <wgrant> No two previewdiffs reference one diff, and no two diffs reference one LFA
[00:55] <StevenK> wgrant: I'm just not sure how to duplicate rows, making sure that FKs are sane and then setting BMP.merge_diff
[00:56] <cjwatson> Isn't bug 497772 released now?  That was apparently in launchpad-buildd 112, and top-of-changelog is 114
[00:56] <_mup_> Bug #497772: exceptions.AttributeError: 'DebianBuildManager' object has no attribute '_subprocess' <oops> <launchpad-buildd:Fix Committed by jelmer> < https://launchpad.net/bugs/497772 >
[00:56] <wgrant> StevenK: I'd probably write a query to find a temp table of the newer BMP of each of the 35 pairs, then execute a PL/pgSQL function to duplicate the three rows and switch the FK
[00:57] <StevenK> cjwatson: Ah, but what launchpad-buildd is deployed on the builders ...
[00:57] <wgrant> 114
[00:57] <wgrant> So yeah, that can be closed
[00:57] <cjwatson> launchpad-buildd | 113~0.IS.08.04 | hardy-cat-buildd | source, all
[00:57] <cjwatson> launchpad-buildd | 113~0.IS.08.04 | lucid-cat-buildd | source, all
[00:57] <cjwatson> But either way ...
[00:57] <wgrant> Buildd toolchain package versions: launchpad-buildd_114-0~53~0.IS.08.04 python-lpbuildd_114-0~53~0.IS.08.04 bzr_2.5.1-0ubuntu2.
[00:57] <cjwatson> Ah, good
[00:57] <wgrant> Mysterious
[00:58] <cjwatson> launchpad-buildd | 114-0~53~0.IS.08.04 | hardy-cat-proposed | source, all
[00:58] <wgrant> Ah
[00:58] <wgrant> Where did you get a cat madison?
[00:58] <cjwatson> chinstrap:~cjwatson/madison-lite-cat/
[00:58] <cjwatson> madison-lite --config=config there
[00:58] <wgrant> Ahh, thanks
[00:59] <cjwatson> And I run ./make-local-mirror occasionally to refresh the local Packages/Sources
[00:59] <cjwatson> Actually in fact that's cronned houry
[00:59] <cjwatson> *hourly
[01:00] <cjwatson> It is a foul hack but it works
[01:03] <cjwatson> Is there any way to get the OOPSen in bug 809937?  Neither lp-oops.c.c nor oops.c.c seems to have them any more
[01:03] <_mup_> Bug #809937: Timeout accepting packages  <queue-page> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/809937 >
[01:04] <cjwatson> I suspect that's a dup of bug 745799, but it would be nice to be able to check
[01:04] <_mup_> Bug #745799: DistroSeries:+queue Timeout accepting packages (bug structural subscriptions) <qa-ok> <timeout> <Launchpad itself:In Progress by cjwatson> < https://launchpad.net/bugs/745799 >
[01:04] <wgrant> It's probably a dupe
[01:05] <wgrant> We'll know for sure when the +queue POST oopses never appear again :)
[01:05] <StevenK> wgrant: So my plan based on your plan is a function that we call once per previewdiff, I'm clear on how to duplicate the data using INSERT INTO, but how do get back the id so I can keep FKs sane?
[01:05] <wgrant> But it may be worth duping that
[01:07] <wgrant> StevenK: INSERT INTO foo (bar, baz) VALUES (what, ever) RETURNING id INTO some_var;
[01:07] <wgrant> RETURNING is normal PostgreSQL; it's how we get the IDs back in Storm
[01:07] <wgrant> INTO is PL/pgSQL
[01:20] <StevenK> wgrant: UPDATE branchmergeproposal SET ... WHERE merge_diff = pd_id LIMIT 1;  doesn't make sense, right?
[01:33] <wgrant> StevenK: Indeed not
[01:33] <wgrant> StevenK: The function will presumably be called with a BMP ID
[01:35] <StevenK> wgrant: I've written it for a previewdiff id
[01:35] <StevenK> It even works
[01:35] <StevenK> Let me pastebin it up so you can insult me.
[01:35] <StevenK> :-P
[01:35] <StevenK> wgrant: http://pastebin.ubuntu.com/1225731/
[01:36] <wgrant> StevenK: Right, easy solution is to use the MP ID instead
[01:36] <wgrant> Then grab the merge_diff from that
[01:37] <StevenK> wgrant: It works this way? :-)
[01:37] <wgrant> Oh, I see you do the SELECT first, right
[01:38] <wgrant> Is that quick enough on DF?
[01:38] <wgrant> If not, just move the SELECT merge_diff bit to before the statement timeout
[01:38] <StevenK> So I've tested one run, I'm just about to try it with -f and a ROLLBACK
[01:38] <wgrant> Right
[01:39] <StevenK> Hah, my end SELECT line is wrong
[01:41] <StevenK> wgrant: It times out. :-(
[01:41] <wgrant> Right, so swap lines 6 and 8
[01:42] <StevenK> wgrant: It times out at INSERT INTO libraryfilealias
[01:42] <StevenK> It already printed SELECT 35
[01:43] <wgrant> Have you explained the INSERT INTO?
[01:43] <StevenK> wgrant: Just about to.
[01:45] <StevenK> wgrant: 3ms
[01:45] <wgrant> Perhaps just a cold cache? Run again?
[01:46] <StevenK> Oooh
[01:47] <StevenK> It prints duplicate_preview_diff, 35 blank rows and then (35 rows), can make it uh, not do that?
[01:47] <StevenK> Into a pager, which results having to hit q
[01:49] <StevenK> wgrant: ^
[01:50] <wgrant> Not sure
[01:50] <wgrant> But it's because the function is returning null
[01:50] <StevenK> wgrant: Actually, I think the SELECT duplicate_preview_diff(merge_diff) ... is doing it
[01:51] <wgrant> Exactly.
[01:52] <wgrant> You asked it to return the result of that function
[01:52] <wgrant> Which is NULL
[01:52] <wgrant> for each row
[01:52] <StevenK> Ah
[01:52] <wgrant> so 35 times
[01:52] <StevenK> But it's declared as RETURNS void ?
[01:52] <wgrant> Which means it returns null
[01:52] <lifeless> out for a short while
[01:52] <wgrant> It just can't return anything itself; it always evaluates to null
[01:53] <StevenK> wgrant: So what do I instead?
[01:53] <wgrant> StevenK: Ignore it, probably
[01:54] <wgrant> I'm sure ops can press q
[01:55] <StevenK> lifeless: I'd like to chat about some SQL I'd like to run on prod when you're back.
[02:01]  * bigjools owes wallyworld_ alcohol for adding the commit msg to MP emails
[02:01] <bigjools> or caffeine, pick your drug of choice
[02:01]  * wallyworld_ likes Southern Comfort
[02:02] <wallyworld_> i assume it worked to your satisfaction then
[02:02] <StevenK> Is that a euphemism for wgrant?
[02:02] <wallyworld_> oooooh
[02:02] <bigjools> haha
[02:21] <wgrant> StevenK: https://oops.canonical.com/oops.py/?oopsid=OOPS-4845cff98595cfa456992a710aaff661 is a bit odd
[02:21] <wgrant> I suspect it's a regression from your stuff
[02:22] <StevenK> Blink
[02:22] <StevenK> Oh, we switched to SRF
[02:22] <wgrant> Ah
[02:22] <wgrant> Yeah
[02:23] <wgrant> And when given a name, I bet it uses BPBSet instead of BFJSet
[02:23] <wgrant> And the former is probably SQLObject
[02:23] <wgrant> Yeah
[03:03] <lifeless> StevenK: hi
[03:12] <StevenK> lifeless: O HAI. The SQL in question is https://pastebin.canonical.com/75216/
[03:13] <lifeless> sudo execute me some sql ?
[03:13] <StevenK> lifeless: The background is that when wgrant and I were migrating staticdiff to previewdiff we didn't check for and discard duplicates, so now we have 35 previewdiffs that are referenced by more than one branchmergeproposal
[03:14] <lifeless> StevenK: I see
[03:14] <lifeless> StevenK: you have  afunction in there; how have you validated it ?
[03:14] <StevenK> lifeless: I ran it on DF
[03:15] <lifeless> StevenK: so if it did the wrong thing, we have no idea ? :)
[03:15] <lifeless> let me give it some eyeballing
[03:17] <lifeless> ok, I **think** it will be ok
[03:18] <StevenK> Right, it is just duplicating the data and then picking one of the BMPs as a victim
[03:19] <StevenK> And we have 2 previewdiffs that are lucky and linked from 3 BMPs
[03:19] <StevenK> So we'll have to run it twice
[03:23] <StevenK> lifeless: If you'd prefer, I'm happy to perform some validation on DF after lunch?
[03:24] <lifeless> that would give me some comfort yes
[03:24] <lifeless> its just a little too large to visually confirm
[03:25] <bigjools> we need a "pebkac" bug status
[03:25] <lifeless> StevenK: like, check it really only updates one of them, not both sides
[03:52] <stub> lifeless: it does, because the final update will fail because the id column is unique and it matches with the = operator.
[03:57] <StevenK> lifeless: http://pastebin.ubuntu.com/1225881/
[04:04] <stub> StevenK: Want me to run it?
[04:05] <StevenK> stub: I was happy enough to go through webops, but please do.
[04:05] <StevenK> stub: You'll need to run it twice -- two lucky previewdiffs are linked to 3 BMPs
[04:07] <stub> StevenK: Done. 35 rows fixed, then 2 in the second run
[04:08] <StevenK> stub: Fantastic, thanks.
[04:24] <wgrant> StevenK, stub: Thanks
[04:24] <wgrant> The broken MPs are no longer broken.
[04:24] <StevenK> It should makes the OOPS report a bit happier too
[04:25] <wgrant> StevenK: Were you going to look at the Builder:+history regression, or should I fix it?
[04:25] <StevenK> wgrant: Can you remind me of that Builder:+history regression and your thoughts on it?
[04:26] <wgrant> StevenK: The OOPS I pointed out this morning. If you look at Builder.getBuildRecords, you'll see it uses a different method if a name filter is specified.
[04:26] <wgrant> BinaryPackageBuildSet.getBuildsForBuilder returns an SQLObjectResultSet, which SRF chokes on
[04:27] <wgrant> So we just need to Stormify BinaryPackageBuildSet.getBuildsForBuilder
[04:27] <wgrant> Probably about 5 minutes of work :)
[04:27] <wgrant> Plus DEATH TO SQLOBJCT
[04:27] <wgrant> +E
[04:28] <StevenK> wgrant: No point for a test, just make it Stormier?
[04:28] <wgrant> I think so.
[04:28] <StevenK> wgrant: Did you see buildbot is still full of hate and not love?
[04:28] <wgrant> Although a test could be done in about 4 lines.
[04:28] <wgrant> StevenK: A second spurious rabbitmq failure? Yeah
[04:28] <wgrant> A bit odd
[04:28] <wgrant> But we'll see if it happens again
[04:33] <StevenK> wgrant: It's a bit more than 5 minutes.
[04:33] <StevenK> BinaryPackageBuildSet.handleOptionalParamsForBuildQueries() is disgusting
[04:34] <wgrant> Oh, I missed that call
[04:35] <wgrant> But it's not that bad
[04:35] <wgrant> The only issue is that you probably have to port the rest as well
[04:35] <StevenK> Yes
[04:35] <wgrant> That's only two other methods, luckily
[04:40] <StevenK> Didn't we write a Storm archive privacy method?
[04:40]  * StevenK tries to remember
[04:43] <lifeless> wgrant: a little more context when downgrading importance would be lovely
[04:44] <lifeless> wgrant: it would avoid questions like 'why isn't it critical', which I might otherwise ask
[04:45] <wgrant> lifeless: The only questionable things I've downgraded are the crashes in ec2 demo
[04:45] <wgrant> AFAICR
[04:45] <lifeless> yah
[04:45] <lifeless> just a -little- context, is all I'm asking for
[04:46] <wgrant> I decided that nobody cares about ec2 demo apart from jml, and it's never been reliable, so it's probably not worth a critical
[04:47] <wgrant> Or two
[04:47] <lifeless> sure
[04:47] <lifeless> but all folk like me see
[04:47] <lifeless> is 'critical->high'
[04:47] <lifeless> with no more info at all
[04:47] <wgrant> True
[04:47] <lifeless> not even the fact its ec2 demo vs ec2 land
[04:48] <lifeless> so just saying 'ec2 demo is a best effort subproject - not treating as critical' would be more than enough
[04:48] <wgrant> [Bug 993300] Re: Error in apache config during ec2 demo
[04:48] <_mup_> Bug #993300: Error in apache config during ec2 demo <ec2> <Launchpad Developer Utilities:Triaged> < https://launchpad.net/bugs/993300 >
[04:48] <wgrant> It says "demo"
[04:48] <wgrant> but k
[05:34] <StevenK> wgrant: Holy crap, I think I win
[05:38] <wgrant> StevenK: What have you broken?
[05:38] <StevenK> wgrant: 3 files changed, 74 insertions(+), 91 deletions(-)
[05:38] <StevenK> It almost works
[05:39] <wgrant> :( +74
[05:39] <lifeless> -91
[05:40] <wgrant> Sure
[05:40] <wgrant> But normally if I frown at him he gets it even more negative
[05:41] <StevenK> It only works sometimes.
[05:41]  * StevenK tries to work out where builder fits in
[06:10] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/stormier-getbuildsforbuilder/+merge/126159
[06:12] <wgrant> StevenK: Looking
[06:46] <StevenK> wgrant: So, I was happy to move that into get_archive_privacy_filter, but BFJ's usage of it wants Or(PackageBuild.id == None, <archive privacy stuff>)
[06:47] <wgrant> StevenK: Does it want it?
[06:47] <wgrant> or is it a bug?
[06:48] <StevenK> I don't think it is
[06:49] <wgrant> Why does BFJ's usage of it want that?
[06:49] <wgrant> Oh, I misread
[06:49] <wgrant> Surely BFJ also wants the admin/anon special cases?
[06:49] <StevenK> It has it!
[06:51] <wgrant> StevenK: And how does it differ?
[06:51] <StevenK> clauses.append(Or(PackageBuild.id == None, Not(Archive._private)))
[06:51] <StevenK> That's the user is None case for BFJ
[06:51] <StevenK> clauses.append(Not(Archive._private))
[06:52] <StevenK> And the one I added in the branch
[06:52] <wgrant> OK, I'm confused
[06:52] <wgrant> "I was happy to move that into get_archive_privacy_filter"
[06:52] <wgrant> What is "that"?
[06:52] <StevenK> I could hack around it by doing if clause: return Or(clause, filter) else return filter
[07:03] <wgrant> StevenK: BuildFarmJobSet.getBuildsForBuilder does the same thing, except in the admin case
[07:03] <wgrant> And get_archive_privacy_filter should return True for an admin
[07:04] <wgrant> So the admin case will be Or(PackageBuild.id == None, True)
[07:04] <wgrant> Which should perform fine
[07:09] <StevenK> wgrant: http://pastebin.ubuntu.com/1226047/
[07:09] <StevenK> It doesn't fix the LIKE bit yet
[07:09] <StevenK> Or my indentation sins
[07:11] <StevenK> wgrant: origin = [PackageBuild] is because it's always used whereas the old code pulled it in later
[07:11] <wgrant> k
[07:12] <StevenK> Hmm, why is where wrapped in brackets with no comma or line wrap
[07:12] <wgrant> StevenK: I'm not sure it's worth having that clause arg
[07:13] <StevenK> wgrant: You'd rather toss Or(PackageBuild.id == None, ...) into BinaryPackageBuild's callsite too?
[07:13] <StevenK> Even though it wasn't there before
[07:13] <wgrant> StevenK: SOmetimes people (eg. me, sometimes) wrap 'where=Foo.bar == baz' in parens
[07:13] <wgrant> To make it less ambiguous
[07:13] <StevenK> Fair enough
[07:13] <wgrant> 'cause it really looks like the = should bind tighter there
[07:13] <wgrant> But it doesn't
[07:13] <StevenK> Trying to work how you'd prefer the filter = [ block to be indented
[07:14] <wgrant> Which?
[07:14] <wgrant> In get_archive_privacy_filter?
[07:14] <StevenK> Yeah
[07:14] <wgrant> The second element of the list is indented further than the first
[07:15] <StevenK> Oh, duh
[07:15] <wgrant> Which doesn't make much sense
[07:15] <wgrant> Yeah
[07:15] <wgrant> StevenK: So, back to PackageBuild.id == None: no, I would include PackageBuild.id == None in BFJS as we do today
[07:15] <StevenK> wgrant: So, PackageBuild.id == None into BinaryPackageBuild's callsite?
[07:16] <wgrant> So it becomes Or(PackageBuild.id == None, get_archive_privacy_filter(user))
[07:16] <StevenK> *get_archive_pri ...
[07:16] <StevenK> :-)
[07:16] <wgrant> Not if it returns an Or, no
[07:16] <StevenK> It wasn't
[07:16] <wgrant> It wasn't, no
[07:16] <wgrant> But it should
[07:16] <StevenK> Or() doesn't make sense for the BPB case
[07:17] <wgrant> It should return Not(Archive._private), or True, or Or(Not(Archive._private), Archive.ownerID.blah)
[07:17] <wgrant> I think
[07:17] <wgrant> Why not?
[07:17] <StevenK> Oh, hmm
[07:18] <StevenK> wgrant: Wait, what about Or(PackageBuild.id == None, Or(...)) ?
[07:18] <wgrant> What about that?
[07:18] <wgrant> It's arguably slightly ugly, but meh?
[07:18] <StevenK> Sorry, is having the or's nested a bad thing?
[07:19] <wgrant> Only if you consider nested ORs to be a bad thing.
[07:19] <wgrant> And I don't see why you would
[07:21] <StevenK> wgrant: http://pastebin.ubuntu.com/1226063/
[07:26] <wgrant> StevenK: Looks reasonable. There's no other admin/anon specialcases in the callsites that you can eliminate?
[07:27] <StevenK> Not that I can see.
[07:27] <wgrant> :(
[07:27] <StevenK> However, I'm going to actually stop work and do the LIKE stuff tomorrow
[07:27] <wgrant> :)
[07:27] <StevenK> So I'll have a dig to see if that function can be grafted into other sections of the code.
[07:28] <StevenK> And it will be glorious, etc, etc
[07:33] <adeuring> good morning
[07:45] <lifeless> right now, what was I doing this morning? Thats right, I was doing a plugin for bzr
[07:45]  * lifeless writes some code
[07:47] <StevenK> lifeless: The morning may have gotten away from you.
[07:47] <lifeless> rather
[08:10] <czajkowski> wallyworld: I see you're working on the text for the commercial email, I have an action item to add some text to that could you point me in the right direction please?
[08:11] <wallyworld> czajkowski: sure. the change has landed already and is awaiting deployment. the file i edited is product-commercial-subscription-expired-open-source.txt in email templates
[08:12] <wallyworld> is this the one you want?
[08:12] <wallyworld> czajkowski: there's a few other templates in the same directory as well
[08:12] <czajkowski> wallyworld: not done this before, basically looking for the mail that is sent to a person after they purchase a subscription so I can add the launchpadstatus feed links on identi.ca/twitter and our blog url
[08:13] <wallyworld> for other commercial emails of various sorts
[08:13] <czajkowski> nods
[08:13] <wallyworld> czajkowski: ok, let me find the template
[08:17] <wallyworld> czajkowski: product-license-other-proprietary.txt is sent when a project is first created with a proprietary licence and gets an initial 30 day subscription, but just right now, i can't find what is sent when a subscription voucher is redeemed
[08:18] <wallyworld> czajkowski: if you overlap with sinzui, he will likely be able to tell you immediately where to look. if if you have a bit of text from an email, i can search for it
[08:21] <czajkowski> wallyworld: I dont but will do in a bit thanks for the help, also see pm for other bit
[09:11] <lifeless> wow
[09:11] <lifeless> I can't get used to this fast buildbot ;)
[09:12] <czajkowski> heh
[09:12] <mgz> I'd say you've been working on launchpad for too long, BUT THAT'S NOT TRUE ;_;
[09:13] <mgz> moving back to a bzr-pqm style landing would be nice, rather than the current complications
[09:16] <StevenK> mgz: Purple has been talking about it
[09:16] <mgz> I trust purple.
[09:16] <StevenK> Means ec2 can just go and die too
[09:16] <lifeless> J
[09:16] <lifeless> E
[09:16] <lifeless> N
[09:16] <lifeless> J
[09:16] <lifeless> I
[09:16] <lifeless> N
[09:16] <lifeless> S
[09:16] <lifeless> *FFFAAARRRXXXXX* at the typo.
[09:16] <mgz> ehehehe
[09:16] <czajkowski> LOL
[09:16] <StevenK> lifeless: Sounds good. Get me hardware and I'll break my back to set it up?
[09:17] <lifeless> StevenK: we have the hardware now; prae as master and commander, huey and dewie as slaves
[09:18] <StevenK> lifeless: I have a plan in the next few days to look at configuring and ec2 instance with LXC as an ssh slave and make sure Jenkins can drive it
[09:21] <wgrant> yeah
[09:21] <wgrant> We discussed on the call this morning about setting up Jenkins to do pre-merge testing using the existing slave setup
[09:28] <nigelb> the server names are getting quite hilarious :P
[09:28] <StevenK> nigelb: huey and dewie are not the real names
[09:29] <StevenK> And prae is praseodymium
[09:29] <nigelb> Oh boy
[09:29] <nigelb> I hope the names don't match up to some sort of internal DNS. That's a hard to type name ;)
[09:29] <mgz> we have codenames for codenames around here,
[09:30] <lifeless> nigelb: they do.
[09:30] <nigelb> lifeless: oh dear
[09:31] <StevenK> Awww, leningradskaya no longer resolves
[09:31] <StevenK> (yes, real server name)
[09:31] <lifeless> nigelb: we just call it praë
[09:31] <nigelb> StevenK: *snicker*
[09:32] <StevenK> nigelb: So there's this thing, called tab complete?
[09:32] <nigelb> Hah.
[09:33] <StevenK> ssh running under zsh will tab complete from known_hosts and .ssh/config
[09:33] <lifeless> there is a helper
[09:33] <nigelb> true true. I use it all the time.
[09:33] <lifeless> that knows about all hosts
[09:33] <lifeless> for Canonical
[09:33] <nigelb> Oooh.
[09:33] <lifeless> (internal only)
[09:34] <lifeless> I don't know if the engine code for it is open - haven't checked. I don't think its super deep though, you can probably invent the same for whereever you are quite easily.
[09:34] <lifeless> bzr tree, metadata populated by sysadmins, pull and run make.
[09:35] <nigelb> ah interesting.
[09:35] <nigelb> I've not yet worked with organizations that's gotten into > 30 servers.
[09:35] <StevenK> Ahh, well ....
[09:35] <StevenK> :-)
[09:36] <nigelb> YEah, small time :P
[09:38] <cjwatson> FWIW, in grumpy mode: I find the business of slang names for servers makes things very difficult to follow; there are times when it's taken me months to realise that what I thought were two different servers people were talking about was actually just one.  Much as I object to the pervasive coining of new initialisms in Ubuntu-land which also confuse newcomers, so it's probably a lost cause ...
[09:44] <wgrant> huey and dewie are sluagh and radande :)
[09:44] <wgrant> And prasé is praseodymium
[10:56] <rick_h_> morning
[11:07] <wgrant> 3
[11:08] <rick_h_> 2
[11:08] <rick_h_> 1
[11:08]  * rick_h_ wonders what happens now
[11:08] <czajkowski> breakage
[11:25] <lifeless> wgrant: lp:~lifeless/+junk/bzr-mkghosts
[11:25] <lifeless> wgrant: You should be able to figure it out from that
[12:21] <sinzui> czajkowski, Lp does not send out email to people who purchase subscriptions. Lp is not the store or salesforce. Lp send emails when the user selects a special licence, or the commercial subscription expires
[12:54] <czajkowski> sinzui: right but I'm looking to add launchpadstatus and blog.launchpad.net urls to *some* mail
[12:54] <czajkowski> which would you suggest
[12:56] <sinzui> czajkowski, I am not sure. Lp doesn't send out emails to people who register projects or teams or join Lp, which happens to be the only cases I think users would want to be reminded up status information
[12:57] <czajkowski> sinzui: the logic behind this was I talked to mrevell about how our commercial owners may not know about lpstatus such as build issues or downtime, and we should possibly link them in one of the mails
[12:57] <czajkowski> so they can reference them
[12:58] <sinzui> well
[12:58] <sinzui> we do not have such an email for customers
[12:58] <czajkowski> hmm ok
[12:59] <sinzui> I suggest the warning email we send to users who select the three odd licenses. The email explains Lp's policies about open source projects
[12:59] <czajkowski> ok thanks
[13:01] <sinzui> czajkowski, lib/lp/registry/emailtemplates/product-license-other-proprietary.txt is sent to the user who chooses Other/Proprietary from the licenses
[13:02] <sinzui> czajkowski, this is the text: http://pastebin.ubuntu.com/1226560/
[13:28] <deryck> abentley, adeuring, rick_h_ -- don't forget to tag any cards review that we should look at today.
[13:43] <czajkowski> deryck: just the person, on the last call we had I said i could do some testing re bp, can you point me in the right direction if it;s ready
[14:14] <deryck> czajkowski, hey, sorry, was on call.....
[14:14] <deryck> czajkowski, so I think the idea would be that you play with privacy on blueprints and see if it works like you expect or if you have questions about it....
[14:15] <deryck> czajkowski, I assume matsubara will do more exploratory testing, actually trying to get it to break.
[14:15] <czajkowski> nods ok
[14:15] <deryck> czajkowski, thanks!
[14:46] <adeuring> frankban_, rick_h_: could one of you please review this MP: https://code.launchpad.net/~adeuring/launchpad/revokeAccessGrants_specs/+merge/126261 ?
[14:46] <rick_h_> adeuring: will do
[14:46] <adeuring> rick_h_ thanks!
[14:53] <rick_h_> adeuring: r=me with one typo in comment
[14:53] <adeuring> rick_h_thanks!
[15:01] <sinzui> jcsackett, do you have time to lp-land https://code.launchpad.net/~jcsackett/launchpad/rip-out-portlet
[15:02] <rick_h_> czajkowski: how about http://ubuntuone.com/4TlJf9tXAV2NDiJvi2i91v as an image or too technical and I should see if we can use the YUI logo or something
[15:02] <czajkowski> cool
[15:02] <czajkowski> rick_h_: thanks
[15:03] <rick_h_> czajkowski: so will get feedback from deryck and I'll get with you to put something together to the world.
[15:03] <rick_h_> thanks for the help/advice!
[15:03] <czajkowski> perfect
[15:03] <czajkowski> just an image helps when we share it on places
[15:03] <czajkowski> default will pull in the lp image
[15:04] <rick_h_> k
[15:06] <deryck> rick_h_, so generally, I like the post very much.  I'm not crazy about the double use of the word modern or modernize....
[15:06] <deryck> rick_h_, I would describe what we had before as ancient. :)  I think it's more like "bleeding edge" now or "easier to keep pace with YUI updates" or something like that.
[15:06] <deryck> wouldn't describe, I meant
[15:07] <rick_h_> deryck: sure
[15:07] <rick_h_> deryck: how about just 'update'
[15:08] <deryck> rick_h_, yeah, that works.
[15:08] <deryck> it was just crusty technically what we had before, but it wasn't not-modern, IMO.
[15:09] <rick_h_> yea, I was just thinking of things like the Y.App more 'modern front end' kind of stuff.
[15:09] <rick_h_> but that's why I get you all to sanity check me :)
[15:09] <rick_h_> http://paste.mitechie.com/show/La3GvwYPeAqqtNralwCs/ tweaked and 'updated' and 'new'
[15:09] <deryck> yeah, I followed what you meant.
[15:09] <deryck> looking now....
[15:11] <deryck> rick_h_, much better.  a final language nit-pick... combo'd could be expanded to comboed, or else rewritten as "combo-loaded"
[15:12] <rick_h_> deryck: yea, thanks much better as combo loaded
[15:21] <rick_h_> czajkowski: ok, so updated text, added some links, and make the paragraphs one line to be more WP friendly http://paste.mitechie.com/show/1nO5FCkCr2lT0viQfJx4/
[15:21] <rick_h_> czajkowski: let me know if there's anything else you need on your end and thanks!
[15:22] <czajkowski> rick_h_: do you want me to add it t the blog ?
[15:22] <rick_h_> czajkowski: yes please
[15:22] <rick_h_> czajkowski: or do I have access? I guess I didn't look if I had access to the blog
[15:24] <czajkowski> stabs 2FA!!!
[15:25] <rick_h_> czajkowski: yea sorry I can log in but don't seem to have any access. If you could post it would appreciate it
[15:25] <czajkowski> I want to find the person who's bright idea was t have it on all the time and make sure they dont ever get beer!
[15:25] <czajkowski> rick_h_: so if you sign in and create a user I can then make you and admin
[15:25] <czajkowski> all LP devs should be able to write posts
[15:25] <rick_h_> czajkowski: ok, I did create a user account
[15:25] <rick_h_> if you can add me I'll post it and not bug you :)
[15:26] <czajkowski> 2 ticks
[15:26] <czajkowski> I need to find you first
[15:26] <rick_h_> rharding? Richard Harding, something like that I'd imagine
[15:26] <czajkowski> ahh I was looking under rick_h_
[15:27] <czajkowski> you're admin now
[15:27] <rick_h_> ty
[15:27] <czajkowski> np :)
[15:54] <jcsackett> sinzui: i was fixing an issue with my colo-repo; looks like you landed it for me?
[15:55] <sinzui> yes
[15:56] <jcsackett> sinzui: ok.
[16:00] <sinzui> jcsackett, I suck. There are two failures that look real, but ec2 test did not see them.
[16:01] <sinzui> jcsackett, I will fix them since I landed it
[16:02] <jcsackett> sinzui: you got caught by something i had been working on -- i had noticed just a handful of references to the db_column and was cleaning them up, but apparently failed to mark the MP back to WIP.
[16:03] <sinzui> oh bugger, we exported that attr.
[16:03] <sinzui> I may need to put it back
[16:03] <czajkowski> sinzui: any idea why this person is rnning into this issue reporting a bug....https://answers.launchpad.net/launchpad/+question/209537
[16:07] <sinzui> czajkowski, no idea since the oops is not there. I suggest runing `ubuntu-bug  initramfs-tools-bin`
[16:07] <sinzui> oh, maybe it is because you need registered gpp-keys to use bug mail
[16:08] <sinzui> czajkowski, we silently drop mail from unknown/unverified senders because it is a huge spam vector
[16:08] <czajkowski> sinzui: he's submitted bugs before so was confused
[16:09] <czajkowski> sually if you get a n oops when reporting the bug, it still gets reported
[16:13] <sinzui> jcsackett, date_next_suggest_packaging is a very obscure attr. I really doubt anyone knows it exists.
[16:14] <jcsackett> sinzui: it wasn't exported for a particular version of the API; does that default to beta or devel?
[16:14] <sinzui> jcsackett,  https://launchpad.net/+apidoc/1.0.html
[16:15] <sinzui> it is listed as 1.0
[16:15] <jcsackett> sinzui: which means we can't just remove it.
[16:15] <jcsackett> i have a branch that adds it back in.
[16:16] <sinzui> oh
[16:16] <sinzui> so I could just land the two test fixes, then you can add an empty attr to support the dead api
[16:16] <jcsackett> sinzui: empty attr?
[16:17] <sinzui> jcsackett, the attr can return None. We are going to remove the column from the db because Lp does not use it
[16:17] <jcsackett> sinzui: ah, so on the model make it an @property that just returns None.
[16:18] <deryck> abentley, adeuring, rick_h_ -- just a heads up, I'm going offline for lunch here shortly, to switch back to the house for the rest of the day.
[16:19] <rick_h_> deryck: rgr
[16:19] <sinzui> jcsackett, we may need a setter to that is silently ignored
[16:21] <jcsackett> sinzui: branch updated.
[16:21] <sinzui> oh, you have a fix? which branch?
[16:22] <jcsackett> sinzui: https://code.launchpad.net/~jcsackett/launchpad/fix-rip-out-portlet/+merge/126288
[16:23] <sinzui> well we want to ripput the tests that want dates too
[16:23]  * sinzui may have the patch for that.
[16:23] <jcsackett> sinzui: but this doesn't address test failures, just the atter.
[16:23] <jcsackett> right.
[16:25]  * sinzui running the tests
[16:27] <sinzui> jcsackett, I can land my branch now to fix the suite, or you can merge my patch and gamble lp-landing it.
[16:27] <jcsackett> sinzui: link?
[16:27] <jcsackett> let me merge it and run the two tests on my machine.
[16:28] <sinzui> jcsackett,  the description for the attr shoulr state it is obsolete
[16:28]  * deryck goes offline for lunch now
[16:28] <sinzui> jcsackett, http://pastebin.ubuntu.com/1226941/
[16:28] <sinzui> jcsackett, your addition though restores the webservice test I changed
[16:29] <jcsackett> sinzui: bloody hell. ok, land yours to unbreak buildbot. i'll resolve the API attr issue separately.
[16:29] <jcsackett> this is getting too tangled.
[16:29] <sinzui> okay
[16:33] <sinzui> jcsackett, so I think think happened because you reused your branch for changes after I did the review
[16:34] <jcsackett> sinzui: you are correct; i meant to put the MP back into WIP when i noticed (what i thought) were just two more lines that needed removal.
[16:34] <sinzui> jcsackett, if you want to reuse a branch, you need to delete the review or change the status back to WIP
[16:34] <sinzui> yes, we agree
[16:36] <sinzui> jcsackett, I think the revised description should be "Obsolete. The date to resume Ubuntu package suggestions."
[16:36] <jcsackett> sinzui: sounds good.
[16:38] <sinzui> jcsackett, merge trunk and put back the webservice test change in http://pastebin.ubuntu.com/1226941/
[16:39] <sinzui> I think everything will pass
[16:40] <czajkowski> rick_h_: nice your blog post is being reshared lots
[16:41] <rick_h_> czajkowski: yay!
[16:41] <rick_h_> now back to my coding hole for the rest of the year
[16:41] <czajkowski> rick_h_: tis ok 2013 is close by you can do another post then
[16:56] <jcsackett> sinzui: https://code.launchpad.net/~jcsackett/launchpad/restore-date_next_suggest_packaging/+merge/126293
[17:00] <sinzui> jcsackett, r=me
[17:01] <jcsackett> sinzui: given the fun we just had, i'm ec2ing just to be sure. it is out now.
[17:26] <danilos> wallyworld, you've got mail (if it goes through, maybe you don't)
[18:55] <rick_h_> jcsackett: got a sec?
[18:55] <jcsackett> rick_h_: probably. what's up?
[18:55] <rick_h_> https://code.launchpad.net/~rharding/launchpad/info_type_events/+merge/126317
[18:55] <rick_h_> want to get eyeballs on my thoughts for the information type banner event setup
[18:55] <rick_h_> see #324 in that diff
[18:56] <rick_h_> and then #295 for using it in the privacy banner and let me know if that makes sense?
[18:57] <jcsackett> rick_h_: looks like we're showing on public and hiding on private...should be the reverse, right?
[18:57] <jcsackett> otherwise this looks sensible, though there is a missing step to make sure the banner updates with the correct text.
[18:58] <jcsackett> i suppose that could just be another thing listening for the change event.
[18:58] <rick_h_> jcsackett: the privacy banner doesn't have the text does it?
[18:58] <rick_h_> that's the beta one?
[18:58] <jcsackett> rick_h_: they both have text.
[18:59] <jcsackett> privacy banner says stuff like "this bug is proprietary" or "this bug is private security."
[18:59] <rick_h_> jcsackett: ah ok so the updateText is manually called
[18:59] <rick_h_> right so I need to find the locations of that and get that into this loop
[18:59] <jcsackett> rick_h_: and privacy banner is also used on +filebug and when a bug is first filed with messages that say the type is blah b/c blah.
[18:59] <rick_h_> no, right, I was only looking at the PrivacyBanner implementation and missed that. Cool thanks
[19:00] <jcsackett> rick_h_: you're welcome.
[19:00] <jcsackett> rick_h_: i really like the update to use events. wanted something like that done when we started with the information type transitions but the todo got lost in the shuffle.
[19:01] <rick_h_> jcsackett: right, so then the choicewidget will be setup to fire an information_type:change event with the new value
[19:01] <jcsackett> rick_h_: right, that's very cool.
[19:01] <rick_h_> and everyone else can listen for is_public/is_private to show/hide unless they need the value
[19:01] <jcsackett> much better than the callback madness.
[19:01] <rick_h_> then they can watch change itself I think
[20:52] <rick_h_> jcsackett: sinzui was "    ForbiddenAttribute: ('date_next_suggest_packaging', <Product at 0x1bb7ac50>)" related error stuff the things you guys fixed today?
[20:52] <rick_h_> my ec2 landing failed with some strange doctests and wondered if it's just a matter of pull trunk and resubmit again
[21:07] <sinzui> rick_h_, that was bad timing.
[21:07] <sinzui> rick_h_ I landed a test fix for it, jcsackett is landing a branch that puts it back for API 1.0
[21:22] <rick_h_> sinzui: ok, thanks. I'll keep an eye out for jcsackett's branch then and retry.
[21:23] <sinzui> rick_h_: you can land now. I landed the test fix and just qaed work from both our squads
[21:24] <rick_h_> sinzui: gotcha, landing away then. Thanks
[21:26] <sinzui> rick_h_, jcsackett's branch is in builbot now actually
[21:27] <rick_h_> sinzui: ok cool. Since it seems the only failures were there I sent it to buildbot and I'll see where it goes.
[21:27] <rick_h_> I'm getting good at lp-land hah
[22:38] <lifeless> flacoste: catchup tomorrow I guess ?
[22:45] <wgrant> yay, masterless webapp
[22:45] <wgrant> it mostly works!
[22:46] <lifeless> wgrant: oh, for downtimes?
[22:46] <wgrant> Yeah
[22:46] <lifeless> wgrant: did you see my link to the plugin ?
[22:46] <wgrant> lifeless: I did, yeah, thanks
[22:46] <wgrant> Looks pretty sensible
[22:46] <wgrant> push doesn't populate ghosts, does it?
[22:46] <wgrant> So we'll need to run it on the remote
[22:47] <lifeless> fetch-ghosts
[22:47] <lifeless> or use bzrlib's repository primitives directlry and do lprepo.fetch(localrepo)
[22:47] <lifeless> that will fetch the lot
[22:47] <wgrant> Right.
[22:48] <lifeless> I'd run it on the repo on praseodymium
[22:48] <lifeless> then use the bzrlib primitives
[22:48] <wgrant> Ah, fetch-ghosts doesn't have a -d
[22:48] <wgrant> Hm
[22:49] <lifeless> l = repository.Repository.open_containing('.')
[22:50] <lifeless> r = repoistory.Repository.open('bzr+ssh://...')
[22:50] <lifeless> r.fetch(l)
[22:50] <lifeless> ^D
[22:50] <wgrant> Yeah
[23:18] <StevenK> wgrant: I just read backscroll again and you don't mention the file to peer at for LIKE gubbins
[23:22] <wgrant> StevenK: Hm, indeed.
[23:22] <wgrant> StevenK: Distribution.searchSourcePackageCaches
[23:22] <wgrant> Search for LIKE
[23:27] <lifeless> wgrant: btw in case it wasn't obvious, the ghosts thing is now maintenance squad prob
[23:34] <wgrant> lifeless: Yep
[23:37] <mwhudson> wgrant: only if you don't have to think about an answer, but why is it that oauthnonce didn't get moved to memcache or something -- was it behaviour in the face of rolled back transactions?
[23:38] <lifeless> never been a need
[23:38] <mwhudson> mm
[23:38] <mwhudson> i'm sure i remember some goal along those lines
[23:38] <mwhudson> probably confused though
[23:38] <lifeless> and retried transactions perhaps
[23:39] <lifeless> it was very high writes at one point
[23:39] <lifeless> but not actually a problem compared to say the builddmaster
[23:39] <wgrant> Retried transactions are the big issue
[23:40] <wgrant> But there's also the issue that nonces are pointless for our oauth implementation...
[23:40] <mwhudson> because ssl?  or something else?
[23:40] <wgrant> Right, SSL
[23:40] <wgrant> I believe OAuth 2.0 actually drops nonces.
[23:41] <wgrant> Because it's intended to be run over SSL
[23:41] <lifeless> OAuth 2 does a lot of things
[23:41] <wgrant> Lots of things do a lot of things :)
[23:41] <mwhudson> i find the security aspects of oauth 1 to be a bit .. odd
[23:41] <mwhudson> like not signing the body
[23:41] <wgrant> Right
[23:41] <wgrant> OAuth 1 is pretty stupid
[23:41] <wgrant> It's from back in the days when people didn't believe that SSL everywhere would work
[23:42] <wgrant> But Launchpad always has, so OAuth 1 was a Bad Idea™ for us
[23:43] <wgrant> We use plaintext signatures, so if you sniff the request you can just replace the nonce and it'll still work...
[23:43] <mwhudson> could launchpad just ignore the nonces then?
[23:43] <wgrant> Right, that's what it's tempting to do after thinking a bit more.
[23:43] <mwhudson> i know nonces in general allow the client to make some decisions about whether to retry a failed request
[23:43] <mwhudson> but well, http also does that i guess
[23:44] <lifeless> er
[23:44] <lifeless> they are solely for replay attack prevention
[23:44] <lifeless> imagine you have an API 'delete 6 months of audit history'
[23:44] <wgrant> Yeah, they're nothing to do with client retries
[23:44] <wgrant> It's just replays
[23:44] <lifeless> you don't want that played at an attackers convenience
[23:44] <wgrant> Which SSL does already
[23:44] <mwhudson> lifeless: i understand that that's the main point yes
[23:45] <lifeless> mwhudson: s/main/entire/ :)
[23:45] <lifeless> wgrant: SSL isn't that robust, sorry.
[23:45] <mwhudson> someone once claimed to me that in a protocol that uses nonces, you can always retry a request if transmission failed
[23:45] <lifeless> wgrant: MITM in corporates is all over the place, and on some country levels too.
[23:45] <mwhudson> because it will get NACKed by the server if it did in fact get through
[23:45] <wgrant> lifeless: We use plaintext sigs
[23:45] <mwhudson> i wasn't entirely convinced by this :)
[23:46] <lifeless> mwhudson: they give you a mechanism that HTTP doesn't intrinsically provide, for once and only once.
[23:46] <mwhudson> lifeless: right
[23:46] <lifeless> mwhudson: but then so do any of a range of other layer-on-http tools, and I wouldn't want to conflate the two things.
[23:46] <wgrant> lifeless: SSL/TLS prevent replay attacks unless someone is MITMing your crypto
[23:46] <lifeless> wgrant: right, which is widespread.
[23:47] <wgrant> And if someone's MITMing it that badly, then they can just get the secret
[23:47] <wgrant> And re"sign" a new request with a new nonce
[23:47] <lifeless> if you generate the secret on the server, yes.
[23:47] <wgrant> Huh?
[23:47] <lifeless> wgrant: DH is all about avoiding that attack.
[23:47] <wgrant> Yes
[23:47] <lifeless> wgrant: on the MITM side, see e.g. 'sslbump' in squi.
[23:47] <wgrant> Sure
[23:48] <wgrant> But if your SSL is MITMed then you're screwed anyway
[23:48] <wgrant> A nonce doesn't help you if you're sending the secret plaintext over the SSL stream
[23:48] <wgrant> Because the attacker just grabs the secret and uses it to sign the new request
[23:48] <wgrant> We can't pretend to defend against successful SSL MITMs.
[23:48] <lifeless> thats why you don't send the secret over the SSL stream, see above under DH
[23:49] <lifeless> I'm not saying what we do is good.
[23:49] <wgrant> But OAuth doesn't use DH...
[23:49] <lifeless> I'm saying that MITM'd SSL isn't the end of the world.
[23:49] <lifeless> wgrant: I know.
[23:49] <wgrant> For our current implementation, MITM'd SSL is the end of the world
[23:49] <lifeless> wgrant: Have you heard me say 'Oauth is wonderful' recently?
[23:49] <wgrant> OAuth 1's nonces are attempting to defend against MITM'd SSL
[23:49] <wgrant> So they're useless
[23:50] <lifeless> of course, it got more fun with the oauth dude spitting the dummy
[23:50] <wgrant> 09:44:40 < wgrant> It's just replays
[23:50] <wgrant> 09:44:43 < wgrant> Which SSL does already
[23:50] <wgrant> 09:45:15 < lifeless> wgrant: SSL isn't that robust, sorry.
[23:50] <mwhudson> if you can mitm ssl you can probably get your hands on the session cookie, which is way easier to abuse :)
[23:50] <wgrant> Or do you mean in general for OAuth, not for us?
[23:50] <wgrant> mwhudson: Exactly
[23:51] <wgrant> In our implementation, if SSL's replay protection is bypassed then we're entirely screwed anyway
[23:52] <wgrant> I think it's pointless for OAuth to try to defend against SSL MITMs, because if you're trying to do that then you'r probably better off using a hardcoded cert anyway
[23:53] <StevenK> wgrant: http://pastebin.ubuntu.com/1227650/
[23:53] <wgrant> StevenK: %%%%%%%% Right.%%%%%%%%
[23:54] <StevenK> Haha
[23:57] <lifeless> mwhudson: one word, CRIME.
[23:58] <wgrant> Well, yeah
[23:58] <wgrant> But it doesn't impact replays
[23:58] <wgrant> Just... everything else
[23:59] <StevenK> wgrant: Tossing that branch at ec2.
[23:59] <StevenK> Jenkins after breakfast
[23:59] <bigjools> can someone help me work out why one of my LP users is getting MP email please?  I have an account "maas-lander" which is a member of "maas-maintainers" and all new MPs are emailed to it because "maas-maintainers is requested to review", despite maas-maintainers having no subscription settings.