[01:45] <lifeless> would someone like to review my zconfig patch, as the maintainer seems to not be doing so :(
[02:09] <wgrant> lifeless: Hm?
[02:09] <wgrant> lifeless: You proposed it into an import
[02:09] <wgrant> I'm not surprised nobody reviewed it
[02:09] <lifeless> abel did that previously; I commented on the bug to grab freds attention too :)
[02:14] <StevenK> I guess foo = [bar if bar.active and bar.baz in supported for bar in all_bars] is malformed?
[02:14] <lifeless> it may want brackets
[02:14] <lifeless> because you have two ins
[02:15] <StevenK> if (bar.active and bar.baz in supported) also gives syntax error
[02:16] <lifeless> oh
[02:16] <lifeless> lol
[02:16] <lifeless> the if goes at the end
[02:16] <lifeless> [bar for bar in all_bars if bar.active and bar.baz in supported]
[02:16] <StevenK> lifeless: Ah! Indeed, thanks
[02:48] <StevenK> Bleh, Launchpad.login_with('foo', 'dogfood') doesn't work :-(
[04:15] <StevenK> wallyworld_: O hai -- do you know much about StormStatementRecorder? I'm invalidating my store, but still can't get it to actually make a query
[04:15] <wallyworld_> you mean record a query?
[04:17] <wallyworld_> it's normally used after flushing the store, eg
[04:17] <wallyworld_>             Store.of(bug).flush()
[04:17] <wallyworld_>             with StormStatementRecorder() as recorder:
[04:17] <wallyworld_>                 previous_dup.markAsDuplicate(bug)
[04:17] <wallyworld_>                 self.assertThat(recorder, HasQueryCount(LessThan(95)))
[04:18] <StevenK> I'm suspecting that it isn't working for the webservice
[04:18] <wallyworld_> i wonder why if that's the case. i can't see why the webservice would not play nicely with it
[04:20] <StevenK> wallyworld_: http://pastebin.ubuntu.com/1186788/
[04:21] <wallyworld_> hmmm. how come you can't test this using the recipes() method directly as part of a unit test?
[04:29] <StevenK> wallyworld_: If I use owner.recipes[0], I get one query. I'm wanting to use the API because lazr marshalls the vocab that the recipe includes and that involves at least two queries, per recipe.
[04:30] <wallyworld_> the vocab marshalling is a constant count though right? and outside our control? so do we need to measure it for these tests?
[04:30] <StevenK> So I've rewritten the vocab, so it shouldn't make any queries, which is exactly what I'm trying to test.
[04:31] <wallyworld_> can you test that as a unit test on the vocab?
[04:31] <StevenK> Personally, I'd like to see it on the API
[04:32] <wallyworld_> i'm not sure why its not working sadly
[04:32] <wallyworld_> i'd have to fire up the debugger and see what's going on
[04:33] <StevenK> wallyworld_: Could I bug you to do so while I do it as well and we'll meet in the middle?
[04:33] <wallyworld_> ok
[04:37] <wgrant> StevenK: launchpadlib_for requires AppServerLayer, doesn't it?
[04:38] <wgrant> Which means it connects to a real appserver
[04:38] <wgrant> So a statement recorder in the test process isn't going to do you much good
[04:38] <wgrant> Also, don't use launchpadlib in tests
[04:38] <wgrant> It's even slower than Launchpad
[04:39] <StevenK> wgrant: Then how I can test the marshalling?
[04:40] <StevenK> Or is the easiest answer "Just don't" ?
[04:40] <wgrant> StevenK: webservice_for_person
[04:40] <wgrant> Gives you a rawer interface
[04:41] <wgrant> Without all the wadllib etc. overhead
[04:41] <wgrant> Just dealing with JSON
[04:41] <wallyworld_> StevenK: QueryCollector is think is what you want to use
[04:41] <wallyworld_> it seems to be the way to collect sql statements for ws interactions?
[04:42] <wgrant> QueryCollector uses the stuff in the request, I think, but it probably still only works if the request is in-process
[04:42] <wgrant> SSR should work fine with webservice_for
[04:43] <StevenK> Now I'm stuck on how to get at the recipes
[04:43] <wgrant> Oh?
[04:45] <StevenK> As changing the ws_owner.recipes[0] call
[04:46] <wgrant> I'd get the recipe from the DB and call canonical_url on it
[04:51] <StevenK> wgrant: Hah, except that canonical_url includes code.launchpad.dev, and webservice_for_person wants no part of that.
[04:53]  * StevenK sprinkles in force_local_path
[04:56] <StevenK> Right, that test in devel is 34 queries. With my rewritten vocab, 28.
[04:57] <wgrant> :)
[04:57] <wgrant> How'd you do it?
[04:57] <wgrant> No longer a SimpleVocabulary?
[04:58] <StevenK> Yeah, it's now a IHugeVocabulary
[05:01] <StevenK> wgrant: Do you want to see a diff or shall I just put it up for review?
[05:07] <wgrant> StevenK: Review!
[05:19] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/sane-buildable-distroseries/+merge/122791
[05:31] <wgrant> wallyworld_: Your stuff made it through buildbot finally
[05:55] <wallyworld_> yes indeed
[05:55] <wallyworld_> it's even ready for qa
[06:04] <wgrant> StevenK: You have a bit of QA too
[06:09] <StevenK> wgrant: Done.
[06:09] <StevenK> Do we want another deployment?
[06:15] <wgrant> We've not ndted in more than 24 hours!
[06:15] <wgrant> So that's not a question
[06:56] <jam> wgrant: you sound like a junky trying to get his fix. "Maaannn, I haven't had an NDT in 24-hours maaannn. i gotta score some NDT"
[07:03] <wgrant> Heh
[07:40] <adeuring> good morning
[08:42] <nigelb> bigjools: heh, we got a pycharm license at work since all our work is open source :)
[08:47] <bigjools> :)
[10:37] <ev> just to confirm, there's no way to go from a binary package to a source package in the API, right? https://bugs.launchpad.net/ubuntu/+source/python-launchpadlib/+bug/597041 leads me to believe this.
[10:37] <_mup_> Bug #597041: No way to get from binary package to source package <amd64> <api> <apport-bug> <lp-soyuz> <maverick> <ppa> <Launchpad itself:Triaged> <python-launchpadlib (Ubuntu):Invalid> < https://launchpad.net/bugs/597041 >
[10:43] <wgrant> ev: There are no binary or source *packages* exposed in the API, just publications of those packages  -- do you mean binary_package_publishing_history and source_package_publishing_history?
[10:43] <wgrant> If so, that's correct, there's no present way to do it
[10:43] <ev> yes, that
[10:44] <ev> hmm okay
[10:44] <ev> thanks
[10:45] <cjwatson> Indeed.  In auto-sync I just worked around it by reading current Sources files.
[10:45] <cjwatson> Which isn't great but in context it's workable enough.
[10:49] <ev> hm, we actually send the source package up in the reports that apport generates
[10:49] <ev> so I'll just grab the first instance from the db for now
[12:22] <stub> No handlers for logger bzr. Does this mean I need to setup that VM now?
[12:23] <stub> TacException: Error running ['/usr/bin/python2.7', '-Wignore::DeprecationWarning', '/home/stub/lp/replication/bin/twistd', '-o', '-y', '/home/stub/lp/replication/daemons/librarian.tac', '--pidfile', '/tmp/tmpeX98el/librarian.pid', '--logfile', '/tmp/tmpeX98el/librarian.log']: unclean stdout/err: No handlers could be found for logger "bzr"
[12:27] <stub> lp_sitecustomize should be fixing that :-/
[12:27] <mgz> stub: means you need to do whichever update launchpad deps you need today
[12:28] <stub> I'll try that again, but I think I'm fully up to date.
[12:28] <mgz> but yeah, if the branch includes my lp_sitecustomise change, I'm suprised there's still a test failure
[12:28] <stub> Not my branch, just looking at the code that is supposed to make this problem go away.
[12:31] <mgz> what's the last rev in the branch with the test failure?
[12:46] <stub> And now I can't even build mailman... grrr...
[12:47] <wgrant> stub: make clean_buildout compile
[12:47] <stub> Yeah, just let me remove the pdb.debug() from lp_sitecustomize.py
[12:57] <stub> hit it harder, it is ok now.
[13:54] <bac> hi jam and mgz, since you've taken an interest in the canonistack instance we're running, i wonder if you'd like to review a branch i just did that opens up management of it to ~launchpad?  it's at https://code.launchpad.net/~bac/lp-tarmac-configs/add-launchpad-members/+merge/122877
[13:56]  * mgz has a look
[13:57] <mgz> Unauthorized: (<Branch u'~bac/lp-tarmac-configs/add-launchpad-members' (651325)>, 'landing_targets', 'launchpad.View')
[13:58] <mgz> bac: maybe you could also open up the branch to launchpad members? :)
[13:58] <bac> mgz: i just tried and thought i had
[13:58] <bac> let me lok
[13:58] <bac> look
[13:59] <bac> mgz: try now
[13:59] <mgz> 200
[14:03] <mgz> is get_lp_people correct? only deals with a limited level of team nesting
[14:03] <mgz> I guess we're not that deeply nested in launchpad anyway...
[14:05] <bac> mgz: team.participants does multiple levels, i believe
[14:06] <mgz> ah, it's a flattened list of everything?
[14:07] <bac> mgz, yes, as compared to .members
[14:09] <abentley> Anyone else getting "AssertionError: newInteraction called while another interaction is active." on ec2 runs?
[14:23] <abentley> deryck: Any idea about this? ^^^
[14:25] <deryck> abentley, isn't that from when you're using one of the page test browsers and don't logout before starting a new operation?
[14:25] <abentley> deryck: Okay, I'll see if that could be it.
[16:07] <abentley> adeuring: reconcile_access_for_artifact is not working for me.  Has all the necessary code been merged?  http://pastebin.ubuntu.com/1187456/
[16:08] <adeuring> abentley: no, it's only in my branch....
[16:11] <abentley> adeuring: Okay, I need a working IAccessArtifactSource.ensure([blueprint]), so I'll wait on your work for the grants.
[16:11] <adeuring> ok
[16:13] <abentley> adeuring: I'll focus on the subscriptions.
[16:13] <adeuring> abentley: but the fix for the the error is really simple
[16:13] <adeuring> abentley: one more "elif ISpeicification.porvidedBy(...)" in _constraintForConcrete()
[16:14] <abentley> adeuring: Okay.
[19:54] <abentley> sinzui: I'm working on Specification.transitionToInformationType, and looking at the bug version, but having trouble understanding who should be automatically subscribed to a Specification.
[19:55] <sinzui> the bug version is being removed in a few weeks. No one needs to be subscribed to bugs when every project uses bugs
[19:55] <sinzui> sharing I mean
[19:55] <sinzui> So the transition only needs to unsubscribe the people who do not already have access
[19:55] <sinzui> You might want to subscribe the person making the change so that they can undo it
[20:28] <abentley> sinzui: Okay, and the idea is that anyone else who needs access will get it by an AccessPolicyGrant?  What about the owner-- it seems like they might not have access via the policy.
[20:29] <sinzui> The owner of the blueprint?
[20:30] <abentley> sinzui: Yes, the owner of the blueprint.
[20:31] <sinzui> What do we do for branches? oh, we give the owner a subscription that the project owner can later revoke
[20:32] <sinzui> abentley, I think this is an odd corner case. This is like a random person creating a blueprint on my project that just happens to relate to a real secret thing I am working on
[20:32] <sinzui> This is unlikely to happen, and if it does, the non-contributor is probably in the wrong
[20:34] <sinzui> abentley, I am sharing ~canonical with all its commercial projects so that our organisation has full access. We advise every commercial project to to do that, I don't think we need to subscribe the blueprint owner or anyone other that the person that changed the information type
[20:34] <abentley> sinzui: Cool.
[20:35] <abentley> sinzui: Thanks for the clarification.
[20:36] <sinzui> np
[22:13] <StevenK> wgrant: e3522ed011014e61b507a1d730726769
[22:30] <StevenK> sinzui: http://www.timeanddate.com/worldclock/meetingtime.html?iso=20120905&p1=240&p2=136&p3=263
[23:35] <StevenK> wgrant: I guess bug 1046024 is untestable and should be marked as such?
[23:35] <_mup_> Bug #1046024: product release finder ignores .apk files <product-release-finder> <qa-needstesting> <trivial> <Launchpad itself:Fix Committed by sinzui> < https://launchpad.net/bugs/1046024 >
[23:36] <wgrant> StevenK: Right
[23:49] <StevenK> wgrant: I guess bug 892511 can be nailed shut since the reoccurance was due to the DC move and sorted out quickly afterward?
[23:49] <_mup_> Bug #892511: recipe build: ERROR: no such option: --allow-fallback-to-native <recipe> <regression> <Launchpad itself:Confirmed> < https://launchpad.net/bugs/892511 >
[23:53] <wgrant> StevenK: Indeed.
[23:53] <wgrant> I wish people wouldn't reopen old long-closed bugs :(
[23:55] <StevenK> I think bug 940168 is fixed too
[23:55] <_mup_> Bug #940168: Two merge requests created on double-click <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/940168 >
[23:55] <wgrant> It's not
[23:55] <StevenK> I've not been able to trigger it
[23:56] <wgrant> StevenK: Just click it twice quickly
[23:56] <wgrant> While the first one is still spinning