[00:19] whoever is trying to and [00:19] *land* [00:19] PQMException: 'Failed to verify signature: gpgv exited with error code 2' [00:19] please be signing, or update your key with losa [00:20] Or it could be OOPS tools branches have PQM subscribed again [00:20] * lifeless checks [00:21] nope [00:21] https://code.launchpad.net/~launchpad-pqm/python-oops-tools/trunk [00:21] besides, this isn't the super-fast-busy-loop that normally creates :) [00:21] Yes, wgrant had that one fixed last night [00:22] what was subscribed / [00:22] launchpad-pqm [00:22] The branch owner. [00:22] bahhh [00:24] ugh wikipedia [00:24] why do I click on links. === wgrant changed the topic of #launchpad-dev to: Performance Tuesday! | https://dev.launchpad.net/ | On call reviewer: wgrant | Critical bugtasks: 263 [00:54] StevenK: https://code.launchpad.net/~wgrant/launchpad/bug-876171/+merge/79639 === leguin.freenode.net changed the topic of #launchpad-dev to: Performance Tuesday! | https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 273 [00:56] wgrant: IDistroSeries._getAll{Sources,Binaries} do not take a status argument [00:57] Oh, sorry, misreading [00:57] StevenK: I would hope not. [00:57] Right. [00:57] There's a .find() hiding in those calls [00:57] I am working around our lack of a PublicationCollection,. [00:59] wgrant: Ignoring my misunderstanding -- r=me [00:59] wallyworld_: Around? [00:59] wgrant: yep [01:00] wallyworld_: Bug #876533 [01:00] <_mup_> Bug #876533: changing the values in Comboboxes on my code page does not update the branch-list shown < https://launchpad.net/bugs/876533 > [01:01] * wallyworld_ still waiting for lp [01:02] wgrant: ah, ok. it works with the ff on [01:02] but not off [01:02] i'll fix it [01:04] Thanks. [01:22] wgrant: wanna review it, and i'll get it in the pipeline https://code.launchpad.net/~wallyworld/launchpad/broken-branch-listing-876533/+merge/79640 [01:23] Oh god, Julian's domination change has landed :( [01:23] It will be months before we can deploy! [01:23] what's the domination change? [01:24] Utter madness [01:24] wallyworld_: Shouldn't that be unconditonal? [01:24] wgrant: nope [01:24] Don't dominate arch-indep binaries if any sources build them [01:24] Or does the post_refresh_hook fire on load too? [01:24] if the ff is there, the setup is done in the js [01:24] that's why i didn't notice it [01:24] because it works fine for us [01:24] post_refresh_hook: hookUpFilterSubmission [01:25] yep [01:25] That's the only call I can see. [01:25] So either post_refresh_hook is a lie, or it's buggy. [01:25] wgrant: nope, that bit is behind the feature flag [01:25] so we need to provide a call when the ff is off [01:25] I realise. [01:25] that's the basis of the bug [01:25] But does post_refresh_hook fire on page load? [01:26] no, only if the ff is on [01:26] It looks like it should be broken when the ff is on as well. [01:26] That's what I mean. [01:26] otherwise that bit of javascript is not executed [01:26] Does post_refresh_hook fire on page load? [01:26] Assuming it's configured. [01:26] yes [01:26] Ahhhh [01:26] How confusing. [01:26] and it works fine then [01:26] OK. [01:27] it will be better when the ff is taken away and it's the same for everyone [01:27] Right, it's just very confusing that post_refresh_hook is executed on load too. [01:27] Approved. [01:28] thanks. post_refresh_hook is not executed though unless ff is on [01:28] anyone up for an oops_amqp revu ? [01:28] wallyworld_: Clearly. [01:28] But it's confusing that it doesn't just apply to refreshes. [01:30] perhaps. the js module calls the hookup when it is done loading and also on refresh [01:30] ie whenever the html form changes [01:31] https://code.launchpad.net/~lifeless/python-oops-amqp/0.0.2/+merge/79637 [01:31] ^ hint, hint [01:34] lifeless: i'll have a look but am working get a web service test to run properly. i'll need a bit of time to ramp up on the ampq stuff. can i do it a bit later? [01:35] wallyworld_: well, I want low turnaround so that I can use it in the next project along [01:35] ah, right [01:36] i'll look now [01:36] wallyworld_: tuesday wgrant is on OCR [01:36] wgrant: ^ ;) [01:36] Sorry, just developing a test case to revert Julian's revision. [01:37] wallyworld_: you're working on a critical regression, I think you should focus on that :) [01:37] lifeless: already fixed [01:37] and in ec2 [01:37] ah cool [01:37] in which case, thank you! [01:37] just a few lines of tales [01:37] wgrant: You want to revert it? [01:38] StevenK: It's far easier to QA if it's reverted. Plus I think it's buggy. [01:38] wgrant: julian didn't dogfoodinate it before landing ? [01:38] He did. [01:41] unity needs a cat-safe mode [01:41] 37 screenshots later.. [01:41] :) [01:41] all with the same second timestamp [01:54] argh, this use-oops-twisted branch is becoming a branch of doom [01:54] fix one test failure, 30 more pop out [01:59] StevenK: http://paste.ubuntu.com/711550/ [01:59] StevenK: That test now fails. [01:59] Passes at devel-3 [01:59] Think that's revert-worthy? [02:02] wgrant: The source is not superseded? [02:02] IE, 1.0's source is not [02:02] Ah, sorry. The binary isn't. [02:03] Arch-indep can no longer supersede arch-specific, and vice-versa. [02:03] Hmmmm [02:03] I think that's pretty clearly undesirable. [02:03] I think you should add that test and then revert Julian's branch [02:03] Or vice-versa [02:03] Other way around, but yes. [02:03] Thanks. [02:13] StevenK: \o/ [02:13] Purple Assasins! [02:13] I lol'd [02:14] wallyworld_: so for clarity, you're doing that review, or wgrant is ? [02:15] lifeless: sorry, i assumed wgrant was [02:15] I'll be done with the revert+test in a few minutes. [02:15] Can do it then.; [02:15] wallyworld_: I think we tied ourselves up in knots :) [02:15] wallyworld_: wgrant: ok, wgrant it is [02:15] ouch [02:18] bwah I missed one more pending change. >< [02:26] right, pushed. *now* we're cooking. Vit gahs [02:30] * wgrant glares disapprovingly at lifeless' implicit relative imports. [02:31] lifeless: Is r10 relevant to anything at all? [02:33] wgrant: very [02:34] Oh? [02:34] wgrant: fallback when amqp is down is a little cronscript that reads from the datedir repo and sends to amqp [02:34] It seems entirely unrelated to the rest of the branch. [02:35] the branches theme is 'stuff I learnt while hacking elsewhere' [02:35] That's slightly unpleasant. [02:35] But OK. [02:35] __init__ no longer sets self.stopping. Deliberate? [02:35] yeah [02:36] calling run_forever twice should work [02:36] Also, are you sure I can't send a message with a body of None? [02:36] You probably can't, but you never know. [02:36] moderately [02:36] can make it a random nonce / guard it if you like [02:36] I'm not sure if its needed or not [02:37] I've seen no reference to optional message bodies in amqp [02:40] lifeless: Won't the retry logic not work if it goes away more than two minutes after the connection was established? [02:42] grah, you are right [02:42] I will fix [02:42] Thanks. [02:55] lifeless: Reviewed, with a few more comments. [02:58] * wgrant unsubscribes canonical-launchpad-branches from review mail on python-oops-amqp [02:58] Since PQM is unhappy. [03:07] wgrant: you know that refactoring that (mild) duplicate keeps the line count in each test as long due to PEP8 line wrapping rules... [03:07] lifeless: But it's going to be much clearer. [03:09] wgrant: The revert and test have landed? [03:09] StevenK: yes. [03:09] Excellent. [03:12] wgrant: actually, its a rabbit hole into that testtools 'function' object has no attribute getDetails [03:12] wgrant: so I want to defer it; I've added a fixture but using it -> death spiral [03:12] lifeless: at least turn it into a helper method. [03:12] On the test class. [03:13] wgrant: so I think that that hurts clarity [03:13] most of those tests have two distinct actors [03:13] the channel and the queue [03:13] All the present boilerplate certainly doesn't aid clarity. [03:13] right [03:13] so I wrote a fixture to get a channel [03:13] and something is wrong and its going to be a yak shaving session to figure it out [03:14] which needs doing(but not now) [03:15] hmm, I have a possible handle, poking [03:18] wgrant: +70 lines -48 lines [03:18] wgrant: (Which is why this was below my tolerance threshold) [03:18] How!? [03:19] pastebin.com/bTKHC5wN [03:21] You could collapse the channel = channel_fixture.channel into the previous statement. [03:21] +22 from the helper, docs, _all_ entry [03:21] And I was imagining the QueueFixture would go into the same helper method. [03:21] Since it's also shared between every test. [03:21] Possibly even the publisher as well. [03:21] way too much hidden in that [03:22] however collapsing the assignment is good [03:22] Hm? Why can't the test just start with a queue name and publisher as instance variables? [03:22] I've done that plenty before [03:22] so I'm going to play the ETIRED card for sympathy :P [03:23] Sympathy card, well played. [03:24] So, all the tests need a channel and a queue, and there's nothing test-specific about that setup. [03:24] Pull it out into setUp(). Problem solved. [03:25] why do i get a 'AttributeError: 'thread._local' object has no attribute 'interaction' error when i try and use 'with person_logged_in(xxx)'? i've tried a few things but can't seem to fix it [03:25] wgrant: Expensive things being in setUp is a mispattern [03:26] surely it matter not that there's no interaction before i try and log in [03:26] wgrant: they are out-of-site, out-of-mind [03:26] wallyworld_: full traceback? [03:26] wgrant: I much prefer seeing whats going on [03:26] Traceback (most recent call last): [03:26] File "/home/ian/projects/lp-branches/devel-sandbox/lib/lp/bugs/model/tests/test_bugtask.py", line 2390, in test_delete_bugtask [03:26] with person_logged_in(db_bug.owner): [03:26] AttributeError: 'thread._local' object has no attribute 'interaction' [03:26] lifeless: Put them in a fixtures class attribute, or something, then? [03:26] This is currently really cluttering boilerplate. [03:26] +48-36 now, which is much better [03:26] I want it killed. [03:26] Somehow. [03:27] wgrant: its not [03:27] wallyworld_: bet it's the security check on bug.owner :/ [03:27] wgrant: yes its the same, but they are the essential actors in these tests [03:27] wgrant: which is different to boilerplate that isn't an essential actor, and which I have great joy encapsulating and hiding [03:27] It's like 12 consecutive lines that's shared between every test. [03:28] They are essential actors for this *class of test*. [03:28] 3, 5 if you could the publisher (which has different params sometimes) [03:28] mwhudson: you mean i have to remove the proxy? [03:28] mwhudson: i've used with person_logged_in(bugtask.owner) ok [03:29] wallyworld_: i don]' [03:29] wallyworld_: i don't know, it's just a guess :-) [03:29] * wallyworld_ tries it [03:29] wgrant: I've pushed up rev 12 [03:32] mwhudson: that got me one step closer thank you. it would have been nice if the error said what was wrong though [03:33] as in authorised attribute access or whatever [03:33] wallyworld_: note that if you inherit from TestCaseWithFactory, you are logged in anonymously in setUp [03:33] Like Zope is going to be nice. [03:34] handling security proxied objects without an interaction is like some metaphor involving explosives [03:35] mwhudson: yes, but before the bit that was failing i was doing a web service call and other stuff so the initial login was gone i think [03:35] ah [03:35] that's a bit naughty [03:35] you could try restoreInteraction() [03:35] that always seemed a bit magical [03:35] Ah, webservice tests are special [03:35] ok. the test case extends WebServiceTestCase. i have followed what others have done i think [03:35] s/c/th/ [03:35] You can't mix factory calls with webservice calls [03:36] wallyworld_: without wanting to be rude [03:36] you need to make actory calls to set up the objects [03:36] wallyworld_: the "others" might not have understood what was going on :-p [03:36] so, webservice calls wipe the interaction [03:36] Create or grab *everything* from the factory/zope, logout() and then deal with only the webservice [03:36] I think someone has a patch up to fix that [03:36] mwhudson: clearly i don't quite either :-) [03:36] StevenK: or login again [03:37] and then if i want to look at the state of the db after making the ws calls, i need to logout and login again? [03:37] I prefer my way. Less chance of blowing off both legs [03:37] wallyworld_: yeah, i have an email i need to write about that, come to think of it [03:37] wallyworld_: Yes [03:37] wgrant: what do you think? [03:38] lifeless: Oh, the diff is updated? [03:38] mwhudson: StevenK: thanks for the help. [03:38] wgrant: yes, or loggerhead :) [03:38] 401 + queue = self.useFixture( [03:39] 402 + QueueFixture(channel, self.getUniqueString)) [03:39] Does that really not fit on one line? [03:39] wgrant: bah, I missed one - all the others were shuffled by channel_fixture [03:39] s/1/3/ [03:40] no, really just the one [03:41] wallyworld_: where is the code that makes a webservice request? [03:41] mwhudson: it's local. i'll push up something in a sec [03:42] lifeless: You could also s/connection_factory/conn_factory/ in the test and get the ChannelFixture stuff down to a single line. [03:42] as it turns out, calloing logout before webservice_for_person doesn't work [03:42] What traceback do you get? [03:42] wgrant: when we feel the urge to do that, its a hint that PEP8 is wrong :) [03:42] 'no local interaction', no real traceback [03:43] PEP 8 is not relevant here. Every coding standard ever is. [03:43] It's not an indentation problem, it's a line length problem. [03:43] precisely [03:43] anyhow, yes I could do that [03:43] however, the focus right now is on this patch [03:44] It looks more reasonable now. [03:44] wallyworld_: If you're doing webservice_for_person(bugtask.owner) that wants you logged in [03:44] You need to grab out the person beforehand [03:45] owner = bugtask.owner ; logout(); webservice_for_person(owner) [03:45] lifeless: Approved. [03:45] That's what I meant by *everything* [03:45] wgrant: thanks [03:45] * StevenK heads out for about 0 [03:45] Sigh [03:46] s/\(0\)/3\1/ [03:47] * wgrant is tempted to make LP mailing lists strip text/html parts. [03:47] s/.*/bye/ 'Fixed' [03:52] mwhudson: so this gets passed the ws stuff but the delete doesn't 'stick' so the last assert fails https://pastebin.canonical.com/54477/ [03:55] wallyworld_: i hope those commit() calls aren't really required [03:55] mwhudson: the first one is [03:56] wallyworld_: i dunno what's going on though, maybe turn on statement logging in postgres? [03:56] or else the ws cannt see the newly created bug [03:56] uh really? [03:56] delightful [03:56] mwhudson: yeah, doing the sql logging now. nb the normal unit tests for this all work [03:57] i've tried removing the first commit and it blows up with a 'not found' error or similar [03:57] oh right, webservicecaller makes an actual http request [03:58] well, not quite [04:00] wallyworld_: i'm in well over my head now [04:00] mwhudson: np. thanks for your input === almaisan-away is now known as al-maisan [05:07] * wallyworld_ goes to get flat tyre fixed [05:08] The one on your car, or your belly? [05:09] ha [05:09] smart-ass [05:09] the new one on my car that went flat overnight :-( [05:20] wallyworld_: clearly you need to get it exchanged ;) === al-maisan is now known as almaisan-away [05:54] lifeless: So a quick scan of your oops/ampq work worries me a bit due to the amount of crap you need to use Rabbit sanely. I'll have a better scan later, but maybe ZeroMQ has less of an implementation burden than I thought (service registry etc.) [05:57] can you expand on what you mean ? [05:59] lifeless: Reconnection logic, EPIPE handling, local queuing - that sort of stuff. That seems flaky with the Rabbit libs making us do the work. In ZeroMQ we get that for free but need to implement some sort of exchange (such as a service registry to allow peer-peer, or a cookbook broker). [06:00] stub: could you do an 'approve' vote on https://code.launchpad.net/~lifeless/python-oops-tools/amqp/+merge/79644 - I think tarmac is not setup for self-review yet [06:01] done [06:01] fingers crossed [06:01] stub: so, we're very close to done with a working rabbit; I think you have a pretty solid point though [06:02] How is 0mq better on those fronts? [06:02] I don't see how it can do local queueing. [06:02] wgrant: you give it a disk path and it spools to disk if the endpoints are unavailable [06:02] wgrant: up to a threshold you set, at which point it either errors or discards (again, you set the policy) [06:03] So messages are retransmitted when it gets back up. But the local storage is not durable, so you lose it if the process terminates. [06:03] wgrant: only applies to pubsub obviously [06:03] But it is free [06:03] Right, we need durability across process restarts. [06:04] There are a lot of 'we needs'. What I'm wondering is if the stuff we need to implement for rabbit is going to be more work or less reliable than the stuff we need to implement for an alternative like ZeroMQ. [06:05] I've got rose coloured glasses on for ZeroMQ though, as I've not used it in anger and haven't gone over the ampq-oops work seriously to see how much of it we would have needed to do with ZeroMQ too. [06:05] stub: disk swaps don't reset on proces death do they ? [06:06] ah, it does [06:06] 'The SWAP file is not recoverable, so if a publisher dies and restarts, it will lose data that was in its transmit buffers, and that was in the network I/O buffers.' [06:07] stub: so, catching EPIPE is pretty shallow; it would be nice not to. We'd still need (for our use case) offline persistent queuing [06:07] I think it has to do with the runtime state (next time you restart, your connections might be completely different and incompatible), and maybe security (if your spool is durable, you need to worry about who can read it rather than keep it in a private temporary file) [06:14] makes sense to me [06:16] stub: OTOH I think its well encapsulated in oops-amqp (I'm about to cleanup the stuff in my useoops lp branch to use the 0.0.2 improvements) [06:16] stub: also once we are on -a- mq, I think its quite easy to transition, message-pair at a time [06:17] I suspect we will want to move some of this encapsulation to lazr.amqp or something for reuse. lazr.ipc? lazr.messaging? [06:18] Yer. I doubt I could argue a switch to ZeroMQ at this point. The Rabbit APIs bug me though. Weird terminology and promote ugly code. [06:18] yeah. There is some stuff in lp.servicces.messsaging, but its a little to keen to be zope integrated to be reusable (plus some of it doesn't carry its own weight) [06:19] I so want the compose-key-combo for theta [06:19] erm, not theta [06:19] the greek letter whose name escapes me that they use [06:20] ø? [06:20] yes [06:20] Ø [06:20] Alt+/ O [06:20] no [06:20] s/Alt/Compose/ [06:20] ø woo [06:20] yeah, its my left windows key [06:21] I use RAlt, since LSuper is for Unity. [06:22] I refuse to perpetuate that annoyance and promote ZeroMQ :-) [06:22] øøø [06:23] øMQ does look reasonably nice, but I'm a bit concerned that they promote it with a video from a PHP conference. [06:24] Oh. [06:24] #is has a better one. [06:24] ∅ [06:25] Although it's not monospaced :/ [06:26] It is a tool though for writing sane PHP since your PHP can easily become a thin layer talking to a middle layer written in something else :-) [06:26] wgrant: compose for that ? [06:26] lifeless: No clue. [06:26] ØMQ is fine [06:27] I wonder if xkeyboard-config knows. [06:27] ∅MQ fails in a monospace font. [06:27] Need a smallish space.. [06:28] ØMQ looks better than ∅MQ in my non-monospace font too. [06:30] We really need to get rid of embedded JS. [06:35] wgrant: You mean all the inline JS? We certainly do need to do that [06:35] Yes. [06:35] wgrant: We really need a global dom ready and a place for all the js to exists [06:35] It's hideous and buggy and blah. [06:35] And TAL makes it even worse. [06:36] sure is [06:37] wgrant: Fixing that up should have a small speed improvement too [06:38] Indeed. [07:50] lifeless previously said that .suspend on a bmp diff job would cause it to retry later [07:51] but is that true [07:52] it looks a bit more like 'suspend' means paused indefinitely [08:02] good morning [08:02] hi Abel [08:06] poolie: The solution should be clear. [08:06] Just schedule a BranchMergeProposalUpdatePreviewDiffUnsuspensionJob! [08:07] Sorry, BranchMergeProposalUpdatePreviewDiffJobUnsuspensionJob [08:07] :) [08:08] i think i can add it to the list of retriable exceptions [08:08] Hallo [08:09] hi there === almaisan-away is now known as al-maisan === jtv1 is now known as jtv [08:52] mrevell: https://dev.launchpad.net/LEP/SSH_OAuth [08:57] so why does the web service interface hate me so? i have a LaunchpadWebServiceCaller instance, i have logged in, but when i try invoking a delete method exposed via @export_destructor_operation, i get a 405 and only GET PUT PATCH POST allowed [08:57] and it swallows the error so i have to hack in debugging to see the response [08:58] its not personal [08:58] it hates everyone equally [08:58] :-) so how so i get it to allow me to invoke a http delete? [09:01] i see for example there's a story test for deleting branches using a similar bit of code but there's no exposed branch delete method that i can see, so i'm not sure how that works [09:17] adeuring: Hi, I'd like to ask you another question about lazr.batchnavigator if you have 5 minutes. [09:17] rvba: sure [09:17] This time it's a *real* question. [09:17] I'm working on bug 872086. [09:17] <_mup_> Bug #872086: Distribution:+ppas and Distribution:+questions issue unlimited queries when memo=0&direction=backwards < https://launchpad.net/bugs/872086 > [09:17] rvba: well, your last one wass quite real too ;) [09:18] I've done the Storm (trivial) fix but I wonder if I should try to also add a small fix to the batchnavigator like I first envisioned. [09:18] * adeuring is reading the bug report... [09:18] My idea was to try to improve how the batchnavigator deals with empty slices (like res[x:x]) to avoid issuing a query. [09:20] But, reading the code in src/lazr/batchnavigator/z3batching/batch.py I see that the way it works, slicing with [start:end+1] to get cleverly get the information about whether or not there are other elements, will make this improvement rather "clumsy" ... [09:21] adeuring: The storm fix will fix the problem so my question to you is: do you think I should try to improve the navigator or not? (after looking at the code I confess I'm not sure it's worth it). [09:22] rvba: in general, it is of course a good idea to "short-cut" queries where you know that the result will be empty, like sequence[n:n]. The problem with StormRangeFactory is that it does not have any knowledge about the possible size of the result set: The SQL OFFSET clause is gone, so you don't have anything that would map to [N:N]. Or am I missing something? [09:23] adeuring: right, that's why I was thinking that the fix could be in src/lazr/batchnavigator/z3batching/batch.py. [09:23] adeuring: But I'm just reading this code for the first time so I might be wrong. [09:24] rvba: this code is a bit messy: It mixes the old batching parameters, like start, with the new ones -- no realy clear separation [09:25] rvba: The class is supposed to rely _only_ on memo values and on a requested batch size [09:25] adeuring: rvba is talking about the List range factory [09:25] adeuring: I think. [09:25] lifeless: ah, right! [09:26] rvba: ok, in that case, tweaking ListRangeFactory is of course reasonable [09:26] * adeuring needs more coffee [09:27] Right, ListRangeFactory, I confess this code messes with my brain a little ;) [09:27] thats entirely my fault [09:27] I took some confused code and made it more capable [09:27] -> and more confused [09:27] hehe [09:28] Okay, I'll see what I can do with ListRangeFactory, thanks lifeless, adeuring. === jam1 is now known as jam === gmb changed the topic of #launchpad-dev to: Performance Tuesday! | https://dev.launchpad.net/ | On call reviewer: gmb | Critical bugtasks: 273 [09:58] gmb: hi there. Could I grovel you for a review? https://code.launchpad.net/~jtv/launchpad/bug-873421/+merge/79662 [10:06] jtv: If you missed a preposition in that sentence, sure. If not, I don't know what being grovelled by you actually entails... [10:07] Just verbing my way around the language. [10:07]