[00:19] <lifeless> whoever is trying to and
[00:19] <lifeless> *land*
[00:19] <lifeless> PQMException: 'Failed to verify signature: gpgv exited with error code 2'
[00:19] <lifeless> please be signing, or update your key with losa
[00:20] <StevenK> Or it could be OOPS tools branches have PQM subscribed again
[00:20]  * lifeless checks
[00:21] <lifeless> nope
[00:21] <lifeless> https://code.launchpad.net/~launchpad-pqm/python-oops-tools/trunk
[00:21] <lifeless> besides, this isn't the super-fast-busy-loop that normally creates :)
[00:21] <StevenK> Yes, wgrant had that one fixed last night
[00:22] <lifeless> what was subscribed /
[00:22] <wgrant> launchpad-pqm
[00:22] <wgrant> The branch owner.
[00:22] <lifeless> bahhh
[00:24] <lifeless> ugh wikipedia
[00:24] <lifeless> why do I click on links.
[00:54] <wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/bug-876171/+merge/79639
[00:56] <StevenK> wgrant: IDistroSeries._getAll{Sources,Binaries} do not take a status argument
[00:57] <StevenK> Oh, sorry, misreading
[00:57] <wgrant> StevenK: I would hope not.
[00:57] <wgrant> Right.
[00:57] <StevenK> There's a .find() hiding in those calls
[00:57] <wgrant> I am working around our lack of a PublicationCollection,.
[00:59] <StevenK> wgrant: Ignoring my misunderstanding -- r=me
[00:59] <wgrant> wallyworld_: Around?
[00:59] <wallyworld_> wgrant: yep
[01:00] <wgrant> wallyworld_: Bug #876533
[01:00] <_mup_> Bug #876533: changing the values in Comboboxes on my code page does not update the branch-list shown <regression> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/876533 >
[01:01]  * wallyworld_ still waiting for lp
[01:02] <wallyworld_> wgrant: ah, ok. it works with the ff on
[01:02] <wallyworld_> but not off
[01:02] <wallyworld_> i'll fix it
[01:04] <wgrant> Thanks.
[01:22] <wallyworld_> 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] <wgrant> Oh god, Julian's domination change has landed :(
[01:23] <wgrant> It will be months before we can deploy!
[01:23] <wallyworld_> what's the domination change?
[01:24] <StevenK> Utter madness
[01:24] <wgrant> wallyworld_: Shouldn't that be unconditonal?
[01:24] <wallyworld_> wgrant: nope
[01:24] <StevenK> Don't dominate arch-indep binaries if any sources build them
[01:24] <wgrant> Or does the post_refresh_hook fire on load too?
[01:24] <wallyworld_> if the ff is there, the setup is done in the js
[01:24] <wallyworld_> that's why i didn't notice it
[01:24] <wallyworld_> because it works fine for us
[01:24] <wgrant>                     post_refresh_hook: hookUpFilterSubmission
[01:25] <wallyworld_> yep
[01:25] <wgrant> That's the only call I can see.
[01:25] <wgrant> So either post_refresh_hook is a lie, or it's buggy.
[01:25] <wallyworld_> wgrant: nope, that bit is behind the feature flag
[01:25] <wallyworld_> so we need to provide a call when the ff is off
[01:25] <wgrant> I realise.
[01:25] <wallyworld_> that's the basis of the bug
[01:25] <wgrant> But does post_refresh_hook fire on page load?
[01:26] <wallyworld_> no, only if the ff is on
[01:26] <wgrant> It looks like it should be broken when the ff is on as well.
[01:26] <wgrant> That's what I mean.
[01:26] <wallyworld_> otherwise that bit of javascript is not executed
[01:26] <wgrant> Does post_refresh_hook fire on page load?
[01:26] <wgrant> Assuming it's configured.
[01:26] <wallyworld_> yes
[01:26] <wgrant> Ahhhh
[01:26] <wgrant> How confusing.
[01:26] <wallyworld_> and it works fine then
[01:26] <wgrant> OK.
[01:27] <wallyworld_> it will be better when the ff is taken away and it's the same for everyone
[01:27] <wgrant> Right, it's just very confusing that post_refresh_hook is executed on load too.
[01:27] <wgrant> Approved.
[01:28] <wallyworld_> thanks.  post_refresh_hook is not executed though unless ff is on
[01:28] <lifeless> anyone up for an oops_amqp revu ?
[01:28] <wgrant> wallyworld_: Clearly.
[01:28] <wgrant> But it's confusing that it doesn't just apply to refreshes.
[01:30] <wallyworld_> perhaps. the js module calls the hookup when it is done loading and also on refresh
[01:30] <wallyworld_> ie whenever the html form changes
[01:31] <lifeless> https://code.launchpad.net/~lifeless/python-oops-amqp/0.0.2/+merge/79637
[01:31] <lifeless> ^ hint, hint
[01:34] <wallyworld_> 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] <lifeless> wallyworld_: well, I want low turnaround so that I can use it in the next project along
[01:35] <wallyworld_> ah, right
[01:36] <wallyworld_> i'll look now
[01:36] <lifeless> wallyworld_: tuesday wgrant is on OCR
[01:36] <lifeless> wgrant: ^ ;)
[01:36] <wgrant> Sorry, just developing a test case to revert Julian's revision.
[01:37] <lifeless> wallyworld_: you're working on a critical regression, I think you should focus on that :)
[01:37] <wallyworld_> lifeless: already fixed
[01:37] <wallyworld_> and in ec2
[01:37] <lifeless> ah cool
[01:37] <lifeless> in which case, thank you!
[01:37] <wallyworld_> just a few lines of tales
[01:37] <StevenK> wgrant: You want to revert it?
[01:38] <wgrant> StevenK: It's far easier to QA if it's reverted. Plus I think it's buggy.
[01:38] <lifeless> wgrant: julian didn't dogfoodinate it before landing ?
[01:38] <wgrant> He did.
[01:41] <lifeless> unity needs a cat-safe mode
[01:41] <lifeless> 37 screenshots later..
[01:41] <mwhudson> :)
[01:41] <lifeless> all with the same second timestamp
[01:54] <lifeless> argh, this use-oops-twisted branch is becoming a branch of doom
[01:54] <lifeless> fix one test failure, 30 more pop out
[01:59] <wgrant> StevenK: http://paste.ubuntu.com/711550/
[01:59] <wgrant> StevenK: That test now fails.
[01:59] <wgrant> Passes at devel-3
[01:59] <wgrant> Think that's revert-worthy?
[02:02] <StevenK> wgrant: The source is not superseded?
[02:02] <StevenK> IE, 1.0's source is not
[02:02] <wgrant> Ah, sorry. The binary isn't.
[02:03] <wgrant> Arch-indep can no longer supersede arch-specific, and vice-versa.
[02:03] <StevenK> Hmmmm
[02:03] <wgrant> I think that's pretty clearly undesirable.
[02:03] <StevenK> I think you should add that test and then revert Julian's branch
[02:03] <StevenK> Or vice-versa
[02:03] <wgrant> Other way around, but yes.
[02:03] <wgrant> Thanks.
[02:13] <nigelb> StevenK: \o/
[02:13] <nigelb> Purple Assasins!
[02:13] <nigelb> I lol'd
[02:14] <lifeless> wallyworld_: so for clarity, you're doing that review, or wgrant is ?
[02:15] <wallyworld_> lifeless: sorry, i assumed wgrant was
[02:15] <wgrant> I'll be done with the revert+test in a few minutes.
[02:15] <wgrant> Can do it then.;
[02:15] <lifeless> wallyworld_: I think we tied ourselves up in knots :)
[02:15] <lifeless> wallyworld_: wgrant: ok, wgrant it is
[02:15] <wallyworld_> ouch
[02:18] <lifeless> bwah I missed one more pending change. ><
[02:26] <lifeless> right, pushed. *now* we're cooking. Vit gahs
[02:30]  * wgrant glares disapprovingly at lifeless' implicit relative imports.
[02:31] <wgrant> lifeless: Is r10 relevant to anything at all?
[02:33] <lifeless> wgrant: very
[02:34] <wgrant> Oh?
[02:34] <lifeless> wgrant: fallback when amqp is down is a little cronscript that reads from the datedir repo and sends to amqp
[02:34] <wgrant> It seems entirely unrelated to the rest of the branch.
[02:35] <lifeless> the branches theme is 'stuff I learnt while hacking elsewhere'
[02:35] <wgrant> That's slightly unpleasant.
[02:35] <wgrant> But OK.
[02:35] <wgrant> __init__ no longer sets self.stopping. Deliberate?
[02:35] <lifeless> yeah
[02:36] <lifeless> calling run_forever twice should work
[02:36] <wgrant> Also, are you sure I can't send a message with a body of None?
[02:36] <wgrant> You probably can't, but you never know.
[02:36] <lifeless> moderately
[02:36] <lifeless> can make it a random nonce / guard it if you like
[02:36] <lifeless> I'm not sure if its needed or not
[02:37] <lifeless> I've seen no reference to optional message bodies in amqp
[02:40] <wgrant> lifeless: Won't the retry logic not work if it goes away more than two minutes after the connection was established?
[02:42] <lifeless> grah, you are right
[02:42] <lifeless> I will fix
[02:42] <wgrant> Thanks.
[02:55] <wgrant> lifeless: Reviewed, with a few more comments.
[02:58]  * wgrant unsubscribes canonical-launchpad-branches from review mail on python-oops-amqp
[02:58] <wgrant> Since PQM is unhappy.
[03:07] <lifeless> 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] <wgrant> lifeless: But it's going to be much clearer.
[03:09] <StevenK> wgrant: The revert and test have landed?
[03:09] <wgrant> StevenK: yes.
[03:09] <StevenK> Excellent.
[03:12] <lifeless> wgrant: actually, its a rabbit hole into that testtools 'function' object has no attribute getDetails
[03:12] <lifeless> wgrant: so I want to defer it; I've added a fixture but using it -> death spiral
[03:12] <wgrant> lifeless: at least turn it into a helper method.
[03:12] <wgrant> On the test class.
[03:13] <lifeless> wgrant: so I think that that hurts clarity
[03:13] <lifeless> most of those tests have two distinct actors
[03:13] <lifeless> the channel and the queue
[03:13] <wgrant> All the present boilerplate certainly doesn't aid clarity.
[03:13] <lifeless> right
[03:13] <lifeless> so I wrote a fixture to get a channel
[03:13] <lifeless> and something is wrong and its going to be a yak shaving session to figure it out
[03:14] <lifeless> which needs doing(but not now)
[03:15] <lifeless> hmm, I have a possible handle, poking
[03:18] <lifeless> wgrant: +70 lines -48 lines
[03:18] <lifeless> wgrant: (Which is why this was below my tolerance threshold)
[03:18] <wgrant> How!?
[03:19] <lifeless> pastebin.com/bTKHC5wN
[03:21] <wgrant> You could collapse the channel = channel_fixture.channel into the previous statement.
[03:21] <lifeless> +22 from the helper, docs, _all_ entry
[03:21] <wgrant> And I was imagining the QueueFixture would go into the same helper method.
[03:21] <wgrant> Since it's also shared between every test.
[03:21] <wgrant> Possibly even the publisher as well.
[03:21] <lifeless> way too much hidden in that
[03:22] <lifeless> however collapsing the assignment is good
[03:22] <wgrant> Hm? Why can't the test just start with a queue name and publisher as instance variables?
[03:22] <lifeless> I've done that plenty before
[03:22] <lifeless> so I'm going to play the ETIRED card for sympathy :P
[03:23] <nigelb> Sympathy card, well played.
[03:24] <wgrant> So, all the tests need a channel and a queue, and there's nothing test-specific about that setup.
[03:24] <wgrant> Pull it out into setUp(). Problem solved.
[03:25] <wallyworld_> 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] <lifeless> wgrant: Expensive things being in setUp is a mispattern
[03:26] <wallyworld_> surely it matter not that there's no interaction before i try and log in
[03:26] <lifeless> wgrant: they are out-of-site, out-of-mind
[03:26] <mwhudson> wallyworld_: full traceback?
[03:26] <lifeless> wgrant: I much prefer seeing whats going on
[03:26] <wallyworld_> Traceback (most recent call last):
[03:26] <wallyworld_>   File "/home/ian/projects/lp-branches/devel-sandbox/lib/lp/bugs/model/tests/test_bugtask.py", line 2390, in test_delete_bugtask
[03:26] <wallyworld_>     with person_logged_in(db_bug.owner):
[03:26] <wallyworld_> AttributeError: 'thread._local' object has no attribute 'interaction'
[03:26] <wgrant> lifeless: Put them in a fixtures class attribute, or something, then?
[03:26] <wgrant> This is currently really cluttering boilerplate.
[03:26] <lifeless> +48-36 now, which is much better
[03:26] <wgrant> I want it killed.
[03:26] <wgrant> Somehow.
[03:27] <lifeless> wgrant: its not
[03:27] <mwhudson> wallyworld_: bet it's the security check on bug.owner :/
[03:27] <lifeless> wgrant: yes its the same, but they are the essential actors in these tests
[03:27] <lifeless> wgrant: which is different to boilerplate that isn't an essential actor, and which I have great joy encapsulating and hiding
[03:27] <wgrant> It's like 12 consecutive lines that's shared between every test.
[03:28] <wgrant> They are essential actors for this *class of test*.
[03:28] <lifeless> 3, 5 if you could the publisher (which has different params sometimes)
[03:28] <wallyworld_> mwhudson: you mean i have to remove the proxy?
[03:28] <wallyworld_> mwhudson: i've used with person_logged_in(bugtask.owner) ok
[03:29] <mwhudson> wallyworld_: i don]'
[03:29] <mwhudson> wallyworld_: i don't know, it's just a guess :-)
[03:29]  * wallyworld_ tries it
[03:29] <lifeless> wgrant: I've pushed up rev 12
[03:32] <wallyworld_> mwhudson: that got me one step closer thank you. it would have been nice if the error said what was wrong though
[03:33] <wallyworld_> as in authorised attribute access or whatever
[03:33] <mwhudson> wallyworld_: note that if you inherit from TestCaseWithFactory, you are logged in anonymously in setUp
[03:33] <StevenK> Like Zope is going to be nice.
[03:34] <mwhudson> handling security proxied objects without an interaction is like some metaphor involving explosives
[03:35] <wallyworld_> 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] <mwhudson> ah
[03:35] <mwhudson> that's a bit naughty
[03:35] <mwhudson> you could try restoreInteraction()
[03:35] <mwhudson> that always seemed a bit magical
[03:35] <StevenK> Ah, webservice tests are special
[03:35] <wallyworld_> ok. the test case extends WebServiceTestCase. i have followed what others have done i think
[03:35] <lifeless> s/c/th/
[03:35] <StevenK> You can't mix factory calls with webservice calls
[03:36] <mwhudson> wallyworld_: without wanting to be rude
[03:36] <wallyworld_> you need to make actory calls to set up the objects
[03:36] <mwhudson> wallyworld_: the "others" might not have understood what was going on :-p
[03:36] <lifeless> so, webservice calls wipe the interaction
[03:36] <StevenK> Create or grab *everything* from the factory/zope, logout() and then deal with only the webservice
[03:36] <lifeless> I think someone has a patch up to fix that
[03:36] <wallyworld_> mwhudson: clearly i don't quite either :-)
[03:36] <lifeless> StevenK: or login again
[03:37] <wallyworld_> 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] <StevenK> I prefer my way. Less chance of blowing off both legs
[03:37] <mwhudson> wallyworld_: yeah, i have an email i need to write about that, come to think of it
[03:37] <StevenK> wallyworld_: Yes
[03:37] <lifeless> wgrant: what do you think?
[03:38] <wgrant> lifeless: Oh, the diff is updated?
[03:38] <wallyworld_> mwhudson: StevenK: thanks for the help.
[03:38] <lifeless> wgrant: yes, or loggerhead :)
[03:38] <wgrant> 401	+ queue = self.useFixture(
[03:39] <wgrant> 402	+ QueueFixture(channel, self.getUniqueString))
[03:39] <wgrant> Does that really not fit on one line?
[03:39] <lifeless> wgrant: bah, I missed one - all the others were shuffled by channel_fixture
[03:39] <lifeless> s/1/3/
[03:40] <lifeless> no, really just the one
[03:41] <mwhudson> wallyworld_: where is the code that makes a webservice request?
[03:41] <wallyworld_> mwhudson: it's local. i'll push up something in a sec
[03:42] <wgrant> lifeless: You could also s/connection_factory/conn_factory/ in the test and get the ChannelFixture stuff down to a single line.
[03:42] <wallyworld_> as it turns out, calloing logout before webservice_for_person doesn't work
[03:42] <StevenK> What traceback do you get?
[03:42] <lifeless> wgrant: when we feel the urge to do that, its a hint that PEP8 is wrong :)
[03:42] <wallyworld_> 'no local interaction', no real traceback
[03:43] <wgrant> PEP 8 is not relevant here. Every coding standard ever is.
[03:43] <wgrant> It's not an indentation problem, it's a line length problem.
[03:43] <lifeless> precisely
[03:43] <lifeless> anyhow, yes I could do that
[03:43] <lifeless> however, the focus right now is on this patch
[03:44] <wgrant> It looks more reasonable now.
[03:44] <StevenK> wallyworld_: If you're doing webservice_for_person(bugtask.owner) that wants you logged in
[03:44] <StevenK> You need to grab out the person beforehand
[03:45] <StevenK> owner = bugtask.owner ; logout(); webservice_for_person(owner)
[03:45] <wgrant> lifeless: Approved.
[03:45] <StevenK> That's what I meant by *everything*
[03:45] <lifeless> wgrant: thanks
[03:45]  * StevenK heads out for about 0
[03:45] <StevenK> Sigh
[03:46] <StevenK> s/\(0\)/3\1/
[03:47]  * wgrant is tempted to make LP mailing lists strip text/html parts.
[03:47] <lifeless> s/.*/bye/ 'Fixed'
[03:52] <wallyworld_> 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] <mwhudson> wallyworld_: i hope those commit() calls aren't really required
[03:55] <wallyworld_> mwhudson: the first one is
[03:56] <mwhudson> wallyworld_: i dunno what's going on though, maybe turn on statement logging in postgres?
[03:56] <wallyworld_> or else the ws cannt see the newly created bug
[03:56] <mwhudson> uh really?
[03:56] <mwhudson> delightful
[03:56] <wallyworld_> mwhudson: yeah, doing the sql logging now. nb the normal unit tests for this all work
[03:57] <wallyworld_> i've tried removing the first commit and it blows up with a 'not found' error or similar
[03:57] <mwhudson> oh right, webservicecaller makes an actual http request
[03:58] <mwhudson> well, not quite
[04:00] <mwhudson> wallyworld_: i'm in well over my head now
[04:00] <wallyworld_> mwhudson: np. thanks for your input
[05:07]  * wallyworld_ goes to get flat tyre fixed
[05:08] <StevenK> The one on your car, or your belly?
[05:09] <wallyworld_> ha
[05:09] <wallyworld_> smart-ass
[05:09] <wallyworld_> the new one on my car that went flat overnight :-(
[05:20] <nigelb> wallyworld_: clearly you need to get it exchanged ;)
[05:54] <stub> 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] <lifeless> can you expand on what you mean ?
[05:59] <stub> 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] <lifeless> 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] <stub> done
[06:01] <lifeless> fingers crossed
[06:01] <lifeless> stub: so, we're very close to done with a working rabbit; I think you have a pretty solid point though
[06:02] <wgrant> How is 0mq better on those fronts?
[06:02] <wgrant> I don't see how it can do local queueing.
[06:02] <lifeless> wgrant: you give it a disk path and it spools to disk if the endpoints are unavailable
[06:02] <lifeless> wgrant: up to a threshold you set, at which point it either errors or discards (again, you set the policy)
[06:03] <stub> 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] <lifeless> wgrant: only applies to pubsub obviously
[06:03] <stub> But it is free
[06:03] <wgrant> Right, we need durability across process restarts.
[06:04] <stub> 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] <stub> 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] <lifeless> stub: disk swaps don't reset on proces death do they ?
[06:06] <lifeless> ah, it does
[06:06] <lifeless> '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] <lifeless> 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] <stub> 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] <lifeless> makes sense to me
[06:16] <lifeless> 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] <lifeless> stub: also once we are on -a- mq, I think its quite easy to transition, message-pair at a time
[06:17] <stub> I suspect we will want to move some of this encapsulation to lazr.amqp or something for reuse. lazr.ipc? lazr.messaging?
[06:18] <stub> 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] <lifeless> 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] <lifeless> I so want the compose-key-combo for theta
[06:19] <lifeless> erm, not theta
[06:19] <lifeless> the greek letter whose name escapes me that they use
[06:20] <wgrant> ø?
[06:20] <lifeless> yes
[06:20] <wgrant> Ø
[06:20] <wgrant> Alt+/ O
[06:20] <lifeless> no
[06:20] <wgrant> s/Alt/Compose/
[06:20] <lifeless> ø woo
[06:20] <lifeless> yeah, its my left windows key
[06:21] <wgrant> I use RAlt, since LSuper is for Unity.
[06:22] <stub> I refuse to perpetuate that annoyance and promote ZeroMQ :-)
[06:22] <lifeless> øøø
[06:23] <wgrant> øMQ does look reasonably nice, but I'm a bit concerned that they promote it with a video from a PHP conference.
[06:24] <wgrant> Oh.
[06:24] <wgrant> #is has a better one.
[06:24] <wgrant> ∅
[06:25] <wgrant> Although it's not monospaced :/
[06:26] <stub> 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] <lifeless> wgrant: compose for that ?
[06:26] <wgrant> lifeless: No clue.
[06:26] <stub> ØMQ is fine
[06:27] <wgrant> I wonder if xkeyboard-config knows.
[06:27] <wgrant> ∅MQ fails in a monospace font.
[06:27] <wgrant> Need a smallish space..
[06:28] <stub> ØMQ looks better than ∅MQ in my non-monospace font too.
[06:30] <wgrant> We really need to get rid of embedded JS.
[06:35] <huwshimi> wgrant: You mean all the inline JS? We certainly do need to do that
[06:35] <wgrant> Yes.
[06:35] <huwshimi> wgrant: We really need a global dom ready and a place for all the js to exists
[06:35] <wgrant> It's hideous and buggy and blah.
[06:35] <wgrant> And TAL makes it even worse.
[06:36] <huwshimi> sure is
[06:37] <huwshimi> wgrant: Fixing that up should have a small speed improvement too
[06:38] <wgrant> Indeed.
[07:50] <poolie> lifeless previously said that .suspend on a bmp diff job would cause it to retry later
[07:51] <poolie> but is that true
[07:52] <poolie> it looks a bit more like 'suspend' means paused indefinitely
[08:02] <adeuring> good morning
[08:02] <jelmer> hi Abel
[08:06] <wgrant> poolie: The solution should be clear.
[08:06] <wgrant> Just schedule a BranchMergeProposalUpdatePreviewDiffUnsuspensionJob!
[08:07] <wgrant> Sorry, BranchMergeProposalUpdatePreviewDiffJobUnsuspensionJob
[08:07] <poolie> :)
[08:08] <poolie> i think i can add it to the list of retriable exceptions
[08:08] <mrevell> Hallo
[08:09] <poolie> hi there
[08:52] <poolie> mrevell: https://dev.launchpad.net/LEP/SSH_OAuth
[08:57] <wallyworld_> 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] <wallyworld_> and it swallows the error so i have to hack in debugging to see the response
[08:58] <lifeless> its not personal
[08:58] <lifeless> it hates everyone equally
[08:58] <wallyworld_> :-) so how so i get it to allow me to invoke a http delete?
[09:01] <wallyworld_> 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] <rvba> adeuring: Hi, I'd like to ask you another question about lazr.batchnavigator if you have 5 minutes.
[09:17] <adeuring> rvba: sure
[09:17] <rvba> This time it's a *real* question.
[09:17] <rvba> I'm working on bug 872086.
[09:17] <_mup_> Bug #872086: Distribution:+ppas and Distribution:+questions issue unlimited queries when memo=0&direction=backwards <regression> <timeout> <Launchpad itself:Triaged> <Storm:In Progress by rvb> < https://launchpad.net/bugs/872086 >
[09:17] <adeuring> rvba: well, your last one wass quite real  too ;)
[09:18] <rvba> 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] <rvba> 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] <rvba> 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] <rvba> 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] <adeuring> 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] <rvba> adeuring: right, that's why I was thinking that the fix could be in src/lazr/batchnavigator/z3batching/batch.py.
[09:23] <rvba> adeuring: But I'm just reading this code for the first time so I might be wrong.
[09:24] <adeuring> 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] <adeuring> rvba: The class is supposed to rely _only_ on memo values and on a requested batch size
[09:25] <lifeless> adeuring: rvba is talking about the List range factory
[09:25] <lifeless> adeuring: I think.
[09:25] <adeuring> lifeless: ah, right!
[09:26] <adeuring> rvba: ok, in that case, tweaking ListRangeFactory is of course reasonable
[09:26]  * adeuring needs more coffee
[09:27] <rvba> Right, ListRangeFactory, I confess this code messes with my brain a little ;)
[09:27] <lifeless> thats entirely my fault
[09:27] <lifeless> I took some confused code and made it more capable
[09:27] <lifeless> -> and more confused
[09:27] <rvba> hehe
[09:28] <rvba> Okay, I'll see what I can do with ListRangeFactory, thanks lifeless, adeuring.
[09:58] <jtv> gmb: hi there.  Could I grovel you for a review?  https://code.launchpad.net/~jtv/launchpad/bug-873421/+merge/79662
[10:06] <gmb> 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] <jtv> Just verbing my way around the language.
[10:07] <jtv> It involves me grovelling.
[10:07] <nigelb> I think the grovelling comes if you refuse to review :P
[10:08] <gmb> jtv: That's fine, then. I didn't know if it was the Launchpad version of Thailand's annual scheduled coup.
[10:09] <nigelb> lol
[10:35] <gmb> jtv: Approved with one comment, discardable as appropriate.
[10:36] <gmb> s/discard/disregard/g
[10:36] <jtv> gmb: thanks.  Perhaps you were thinking of “shovelling someone” rather than “grovelling someone” earlier.
[10:36] <gmb> Heh.
[10:41]  * gmb -> adding tea to brain; bbiab
[10:48] <jtv> Making an interface attribute doNotSnapshot does not affect our definition of API compatibility, right?  ISTR some programs could theoretically break because of it, but we considered such programs buggy.
[10:50] <gmb> jtv: Right, it shouldn't make a difference to API compatibility.
[10:50] <jtv> Thanks.
[13:07] <deryck> Morning, all.
[13:07] <abentley> deryck: morning.
[13:29] <lifeless> bigjools: allenap: what would cause txlongpoll to timeout on 'make rune'
[13:29] <lifeless> s/rune/run/
[13:30] <allenap> lifeless: Blimey, let me see...
[13:30] <lifeless> 'Exception: Timeout waiting for txlongpoll to start.'
[13:30] <lifeless> plus a trace back - > total output
[13:31] <lifeless> presumably the fixture has a log in getDetails but we're not printing that
[13:31] <bigjools> mmm it tries to connect on the frontend port
[13:31] <bigjools> and won't continue until it connects
[13:31] <bigjools> or times out
[13:31] <lifeless> ok; is that something I would need to fiddle, add to hosts, ... ?
[13:31] <bigjools> so I expect txlongpoll is failing to start up
[13:31] <bigjools> can you run it standalone?
[13:32] <lifeless> I don't know. how do I check?
[13:33] <bigjools> run the binary!
[13:33] <bigjools> well, "executable"
[13:33] <lifeless> help me out here, its 0230 :)
[13:33] <bigjools> bin/twistd-for-txlongpoll
[13:33] <lifeless> [only awake due to unhappy baby]
[13:34] <allenap> lifeless: I suggest adding a try...except: print $fixture_details in TxLongPollServer.setUp() (in the LP code base).
[13:34] <lifeless> that returns a twistd options page
[13:34] <bigjools> bin/twistd-for-txlongpoll  amqp-longpoll -f 9999 -u guest -a guest
[13:34] <lifeless> ah! thanks
[13:35] <bigjools> unless the port that the fixture is using is conflicting with something...
[13:35] <lifeless> assert fallback is None or callable(fallback)
[13:35] <lifeless> I'm guessing I dont' have your fixed txlongpoll
[13:35] <lifeless> in this branch
[13:39] <lifeless> yah, trunk has 0.2.8->0.2.9
[13:39] <lifeless> thanks!
[13:52] <lifeless> allenap: bigjools: does 'make run' run its own rabbit up ?
[13:54] <allenap> lifeless: Yes, should do.
[13:56] <lifeless> allenap: yes, I see
[14:10] <jcsackett> wallyworld: you still actually around?
[14:10] <wallyworld> jcsackett: sadly yes
[14:10] <wallyworld> but off to bed soon
[14:10]  * rvba takes a look at the world clock.
[14:10] <jcsackett> rvba: he's up very late. :-P
[14:11] <rvba> Very very late indeed.
[14:11] <lifeless> pish
[14:11] <jcsackett> lifeless: your habits can't be used to judge anyone else, for various reasons. :-P
[14:12] <jcsackett> although you're up late by most standards too. :-)
[14:12] <nigelb> Actually, with lifeless its hard to judge if he's up late or awake eearly.
[14:13] <jcsackett> hm. that's *very* true.
[14:15] <lifeless> \o/ \o/ \o/ \o/ \o/ \o/
[14:15] <lifeless> instant-oops-delivery end to end manual test is go.
[14:16] <lifeless> code.launchpad.dev/++oops++ -> 'received OOPS-...' on the amqp2disk console (run with -v); paste that into oops-tools web UI and tada immediately visible.
[14:22] <jcsackett> nice!
[14:45] <lifeless> gnight
[14:46] <rvba> nn
[14:54] <flacoste> rvba, allenap: i'm trying to find the cause of bug 830676, can you help me navigate the involved templates?
[14:54] <_mup_> Bug #830676: Regression in PPA AJAX build status indicators <critical-analysis> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/830676 >
[14:55] <allenap> flacoste: Do you mind if I leave you in rvba's hands? I'm meant to be on leave :)
[14:55] <rvba> flacoste: sure.
[14:55] <flacoste> allenap: please be on leave!
[14:55] <rvba> Let me have a look.
[14:55] <flacoste> rvba: i'm utterly unfamiliar with how this is all hooked up together
[14:56] <flacoste> my guess is that the change is done by doUpdate in archive-packages.pt
[14:56] <flacoste> but i don't see where doUpdate is called from
[14:57] <flacoste> or even if this is the right place to look
[14:57] <rvba> looking
[14:59] <flacoste> hmm, although i think this is for the expander part, not the portlet that the bug report talks about
[15:02]  * rvba uploads a test package to a ppa to see the ajax request.
[15:02] <flacoste> rvba: ok, i think this is related to lp.soyuz.dynamic_dom_updater
[15:06] <rvba> flacoste: sounds like the soyuz way indeed.
[15:06] <flacoste> rvba: do you know where the domupdater is hooked to a specific row in the build status column?
[15:07] <flacoste> ah, update_build_status.js
[15:08] <rvba> flacoste: The key is to provide the domUpdateFunction.
[15:08] <flacoste> rvba: right, i'm looking at how this is all hooked up, like everytime you disturb someone to ask questions, you start making progress yourself!
[15:09] <rvba> flacoste: so that's good, let's continue ;)
[15:09] <flacoste> rvba: thanks for helping, i'll continue to investigate and bug you again if i get stuck :-)
[15:09] <flacoste> rvba: i need to hop on a call
[15:09] <rvba> k
[15:19] <abentley> gmb: flacoste thinks my work on reordering bugs via ajax may overlap with your work on loading comments incrementally via ajax.  Can we chat?
[15:21] <gmb> abentley: Certainly. I'll be free to talk in ~30mins if that's okay.
[15:21] <abentley> gmb: works for me.
[15:21] <gmb> abentley: Cool. I'll ping when I'm free.
[15:55] <gmb> abentley: I'm free whenever you are. What works for you, mumble or skype?
[15:55] <abentley> gmb: let's mumble in Orange 101
[15:55] <gmb> abentley: Okidoke. 1 sec...
[15:55] <elmo> a lot of the launchpad buildds are going down  for power work
[15:58] <jtv> gmb: still ocr'ing?  If so, https://code.launchpad.net/~jtv/launchpad/bug-870130/+merge/79691
[15:58] <gmb> jtv: Certainly; bear with me a little while and I'll take a look.
[15:58] <jtv> I often feel bad about hitting the same reviewer twice in one day, though nowhere near as much as for reviewing the same developer twice in one day.
[15:58] <jtv> It's a good thing I enjoy watching them suffer, or I'd be depressed.
[15:58] <jtv> Thanks gmb
[16:23] <abentley> deryck: We have form fields with ids such as "field.searchtext".  I'm having trouble retrieving them with YUI.one.  I think they may be invalid identifiers: http://www.w3.org/TR/CSS2/syndata.html
[16:23] <deryck> abentley, they are invalid.
[16:23] <deryck> abentley, there's some selector work around, but it escapes me now.  let me search.
[16:23] <abentley> deryck: okay.
[16:25] <abentley> deryck: [id=field.searchtext] seems to work.
[16:26] <deryck> abentley, ah right.
[16:27] <deryck> abentley, I was thinking of this construction:  Y.one(Y.DOM.byId('field.searchtext'))
[16:28] <abentley> deryck: Y.one accepts a DOM node?  Weird.
[16:29] <abentley> deryck: also, we seem to have a bunch of ids that are not unique, e.g. field.status.  Should I just give up and jam this stuff into the IJSONCache instead?
[16:29] <deryck> abentley, yeah.  turns it into the Y.Node form.
[16:30] <deryck> hmmm, thinking about that....
[16:30] <deryck> abentley, I think I would stick it in the cache, yes.  Just to be careful and specific.
[16:31] <abentley> deryck: Okay, I'll do that.
[16:55] <gmb> jtv: Approved.
[17:02] <jtv> thanks gmb
[17:02] <gmb> np
[17:02] <gmb> And with that...
[17:03]  * gmb -> afk for the evening
[17:07] <jtv> Then next continent over is giving up?  Classic cue to stop working.
[17:08] <Ursinha> lol
[17:09] <jtv> hey Ursinha!
[17:11] <Ursinha> hey jtv!
[17:11] <Ursinha> :)
[17:15] <nigelb> jtv: heh.
[17:32] <flacoste> abentley, deryck: we should fix the the non-unique ids at some point
[17:42] <abentley> flacoste: and make them valid ids, too.
[17:58] <jtv> Arrrgh buildbot failure.  Something about bzr and twisted, I think.
[17:59] <dobey> haha. launchpad /is/ engineered like an AK-47 no? jams all the time, and lubricated with vodka?
[17:59] <jtv> dobey: no, that's just barry.
[18:00] <jtv> At least, I hear he jams a lot.  Not 100% sure about the vodka.
[18:03] <jtv> jelmer: do you have any idea what might have earned us the ongoing buildbot failure?  https://lpbuildbot.canonical.com/builders/lucid_lp/builds/1476/steps/shell_6/logs/summary
[18:04] <jtv> Most of the failing tests are related to something I touched the other day, but not the first one.  So I'm hoping that first one is closer to the root cause. :)
[18:05] <jelmer> jtv: hmm
[18:06] <jelmer> jtv: that's an odd one. I'm not aware of any other changes in this area. How long has this been failing?
[18:06] <abentley> deryck: Having trouble finding the spot where the search params are defined.  Any suggestions?
[18:06] <jtv> jelmer: only just now, I think
[18:06] <jtv> It looks like it might be transient, maybe timing-sensitive.
[18:07] <deryck> abentley, are you looking for lp.bugs.interfaces.bugtask.BugTaskSearchParams ?
[18:08] <jtv> allenap: nothing to do with your fix to un-hose our librarian tests?  https://lpbuildbot.canonical.com/builders/lucid_lp/builds/1476/steps/shell_6/logs/summary
[18:08] <abentley> deryck: No, I
[18:09] <abentley> deryck: 'm trying to figure out how it gets populated, so I can do it in the right place.
[18:11] <deryck> abentley, lp.bugs.browser.bugtask.BugTaskSearchListingView.buildSearchParams ?
[18:11] <abentley> deryck: Yes, but how does that get called?
[18:12] <abentley> deryck: it gets supplied with extra_params, and I don't know how to get them.'
[18:14] <deryck> abentley, same file, look for search --> searchUnbatched --> buildSearchParams.  Or are you asking how extra_params gets supplied from that top function?
[18:15] <abentley> deryck: Yeah, I still need to know how extra_params get supplied to search().
[18:16] <deryck> abentley, IIRC, I don't think that's used much.
[18:16] <deryck> abentley, I'm looking around.
[18:17] <abentley> deryck: I backtraced to eggs/zope.tales-3.4.0-py2.6.egg/zope/tales/expressions.py(211)_eval()
[18:23] <deryck> abentley, I don't see it actually used anywhere.  You have some error, I take it, where you see extra_params being passed in?
[18:23] <abentley> I don't know if extra_params is used anywhere, but I thought it was how the extra search parameters were getting into the page.
[18:35] <deryck> abentley, so I think buildSearchParams is just doing the work. and data gets populated with the self._validate call.  after that it's Zope magic to me.
[19:00] <flacoste> gary_poster: WebserviceTestCase uses the AppServerLayer, wouldn't it be possible to use wsgi.intercept instead and run in the LaunchpadLayer?
[19:00] <flacoste> or even DatabaseLayer
[19:00] <flacoste> DatbaseFunctionalLayer
[19:00] <flacoste> and let users who need the librarian to upgrade their layer
[19:00] <flacoste> gary_poster: i remember you adding support to use launchpadlib with wsgi.intercept for tests
[19:01] <flacoste> but it seems the default testcase base class for that (and that is getting significant traction by devs) isn't taking advantage of that
[19:05] <gary_poster> flacoste on call, off soon
[19:06] <gary_poster> flacoste, I did add wsgi.intercept for launchpadlib, yeah
[19:06] <gary_poster> lemme see where that was
[19:08] <gary_poster> flacoste, it is in the FunctionalLayer
[19:09] <gary_poster> So in DatabaseFunctionalLayer
[19:09] <gary_poster> LaunchpadFunctionalLayer
[19:09] <flacoste> gary_poster: so in theory, we should be able to change WebserviceTestCase to remove the layer attribute
[19:09] <flacoste> or change it to layer = DatabaseFunctionalLayer
[19:10] <flacoste> and everything should be honky dory?
[19:13] <flacoste> gary_poster: ready on skype whenever you are
[19:13] <gary_poster> flacoste, or any of the non-appserver layers, yeah.  it expects to answer on "localhost:80" and "api.launchpad.dev:80"
[19:13] <gary_poster> ok
[19:19] <benji> Does anyone want to review an exciting and well-written MP?
[19:19]  * benji pretends as if he's not exaggerating.
[20:03] <flacoste> benji: if this is the stakeholders' bug i'm thinking it is, i can have a shot at it
[20:03] <benji> flacoste: it probably is: https://code.launchpad.net/~benji/launchpad/bug-828572/+merge/79733
[20:05] <flacoste> benji: ok, i'm on it
[20:05] <benji> cool
[20:21] <flacoste> benji: looks very good, but i have two questions
[20:21] <flacoste> 1) is there anything we should remove since the garbo migration is complete?
[20:22] <flacoste> (code)
[20:22] <flacoste> 2) since any() in this case is all about status items, couldn't we use search_value_to_where_condition() instead of using recursion and joining with ' OR '?
[20:23] <benji> flacoste: 1) probably; I was thinking the same thing but I was temted to wait until I can ask Brad when he gets back, but honestly it's very, very likely that we should just remove the code from garbo
[20:24] <flacoste> yes, if the transition is complete, we should remove it
[20:25] <benji> flacoste:  2) I don't see an easy way because we have the odd-man-out of having a special case for INCOMPLETE; we could do it but the code would get quite a bit more complex
[20:33] <benji> flacoste: that was odd, my internet connection dropped on me, did you see my response to 2?
[20:37] <flacoste> benji: i did, you basically mean that we'd need to support any() in search_value_to_where_condition
[20:38] <flacoste> benji: which it seems to support :-)
[20:38] <flacoste> hmm
[20:39] <flacoste> actually
[20:39] <flacoste> no
[20:39] <flacoste> it supports a single any
[20:39] <flacoste> ok, so that should be fine then
[20:39] <benji> flacoste: no (although that may be true), I mean that since the user can provide something like any(NEW, INCOMPLETE) we would have to generate something like "status IN (1, 2, 3)", where 2 and 3 are the enum values for INCOMPLETE_WITH_RESPONSE and INCOMPLETE_WITHOUT_RESPONSE
[20:39] <flacoste> right
[20:40] <flacoste> that's what i understood
[20:42] <flacoste> benji: how about:
[20:42] <flacoste> if INCOMPLETE in status.query_values:
[20:43] <flacoste>    status = any([value for value in status.query_values if value != INCOMPLETE] + [INCOMPLETE_WITH, INCOMPLETE_WIHTOUT)
[20:48] <benji> flacoste: I assume you mean for that to be inside the "if zope_isinstance(status, any)" clause.
[20:50] <flacoste> yep
[20:50] <flacoste> benji: feel free to use it or something like that if you feel it simplifies
[20:50] <flacoste> your mp is approved anyway :-)
[20:53] <benji> flacoste: thanks; I'm experimenting with a variation that might result in equally straight-forward code while also generating the slightly nice SQL you're looking for
[20:53] <flacoste> that'd be awesome
[21:03] <abentley> wallyworld_: flacoste has pointed out that your work on batchnavigator and mine on dynamic bug listings may overlap.  Can we chat?
[21:04] <wallyworld_> abentley: sure
[21:04] <abentley> wallyworld_: skype or mumple?
[21:04] <wallyworld_> either. let's try mumble
[21:14] <benji> flacoste: it turned out quite nicely, thanks for the prod in that direction: http://paste.ubuntu.com/712484/
[21:16] <flacoste> benji: indeed!
[21:17] <flacoste> that's nice
[22:24] <wallyworld_> wgrant: https://code.launchpad.net/~wallyworld/launchpad/delete-bugtasks-1324/+merge/79541
[22:52] <lifeless> flacoste: wow you're churning out critical-analysis tags now :)
[23:02] <lifeless> sinzui: ping
[23:02] <lifeless> sinzui: I want to talk failfan with you
[23:02] <lifeless> sinzui: at a mutually convenient time
[23:04] <lifeless> sinzui: also, StevenK wgrant and I were talking about private teams & socialisation, without you :( [you were on public holiday I think :))] - I'd like to confirm the conclusions with you
[23:11] <wgrant> lifeless: He's out at the moment. Was planning to talk about private teams in 1.5 or 2 hours or so.
[23:11] <wgrant> failfan?
[23:11] <lifeless> mailman
[23:11] <lifeless> but I wanted to say fail
[23:12] <lifeless> wgrant: ok, well ping me (perhaps on skype) - I'm not here today, but meh... will swap things around on thurs/fri
[23:12] <wgrant> Ah!
[23:15] <lifeless> I was working at 4am...
[23:16] <wgrant> ... bad lifeless
[23:16] <lifeless> but working amqp oopses
[23:16] <lifeless> \o/
[23:46] <cjwatson> wgrant: so I've just been talking with slangasek about getting cron.germinate optimisation onto my official to-do list for 12.04, which will hopefully happen
[23:47] <cjwatson> wgrant: it looks to me that its runtime is currently 9-10 minutes, 8 flavours * 5 architectures, and I would be surprised if I couldn't trim at least three-quarters of that
[23:47] <wgrant> Yeah, it should be pretty cuttable.
[23:47] <wgrant> That's excellent news.
[23:48] <cjwatson> wgrant: that would mean that quite a few, but not all, publisher runs would fit within 30 minutes (looking at a sample of today)
[23:48] <cjwatson> what do you think the threshold might be for switching to */30 runs?
[23:48] <wgrant> And we can cut it down further if we split partner out...
[23:49] <cjwatson> also parallelising ls-lR against other stuff, perhaps
[23:49]  * wgrant finds a recent log.
[23:49] <wgrant> I really should get it bumped up to DEBUG.
[23:49] <wgrant> It's a bit quiet at the moment.
[23:49] <cjwatson> ls-lR runtime isn't logged at the moment, no
[23:50] <cjwatson> I had to watch it in action.  I didn't time that step specifically but it took a couple of minutes.
[23:50] <cjwatson> actually from 23:27:00 to I think something around 23:30:40
[23:50] <wgrant> I had a detailed timeline in a Tomboy note a year or so ago. I wonder if that's still around, or if that was in the batch that U1 deleted...
[23:51] <wgrant> Ah, there it is.
[23:51] <wgrant> I have ls-lR down as taking 2.5-3 minutes.
[23:51] <wgrant> Germinate 7, but we have more flavours now.
[23:51] <cjwatson> and one extra arch
[23:52] <wgrant> I think this may have been before the powerpc/sparc elimination, but I don't quite recall.
[23:52] <cjwatson> ah, could be
[23:52] <cjwatson> (powerpc hasn't been eliminated though, maybe you mean lpia)
[23:52] <cjwatson> (or hppa)
[23:52] <wgrant> I meant ia64
[23:52] <wgrant> ia64/sparc
[23:52] <cjwatson> all these doorstops
[23:52] <StevenK> Haha
[23:53] <wgrant> I count sparc and powerpc as real archs, so I forgot about ia64.
[23:54] <cjwatson> I haven't measured (I know ...) but it strikes me that ls-lR is I/O-bound while at least cron.germinate (and possibly other finalize.d type stuff) really aren't
[23:54] <wgrant> That would indeed make sense.
[23:54] <cjwatson> and cocoplum has four CPUs ...
[23:56] <cjwatson> Is splitting out partner a near-future kind of thing?
[23:56] <cjwatson> or merely priority High?
[23:56] <wgrant> Near future doesn't even come from Critical importance.
[23:56] <wgrant> it comes from someone doing it in violation of policy :)
[23:57] <cjwatson> well, LP queue ordering policy doesn't apply to external contributors so no violation involved :-)  but I don't think I'd know where to start
[23:58] <wgrant> I'm not sure that partner actually takes more than a few seconds, though, so it might not be worth it now that it's all in Python.
[23:58] <mwhudson> data data data
[23:58] <cjwatson> mm, I don't see much in the log I can clearly attribute to it
[23:58] <wgrant> Previously partner had ~a minute of LP process startup time. Now it's all in one process, so it's almost free.
[23:58] <wgrant> I'm getting data :)