[00:31] <rick_h_> huwshimi: https://github.com/yui/yui3-gallery/tree/master/build/gallery-anim-morph woot!
[00:32] <rick_h_> https://github.com/yui/yui3-gallery/tree/master/src/gallery-anim-morph for the source with the api docs
[00:32] <huwshimi> rick_h_: Fantastic!
[00:33] <rick_h_> so first gallery module done, working on a couple more, but good to get the ball rolling
[00:38] <huwshimi> rick_h_: Yeah, feels like we're doing this properly now.
[04:28] <StevenK> wgrant: Clearly, AccessArtifactGrantSource.grant([artifact, subscriber]) is not the right way to call it, and I can't work out the right way from the code.
[04:29] <wgrant> StevenK: AccessArtifactGrantSource.grant([(artifact, grantee, grantor), ...]), IIRC, but let me check the interface
[04:29] <wgrant>     def grant(grants):
[04:29] <wgrant>         """Create `IAccessArtifactGrant`s.
[04:29] <wgrant>         :param grants: a collection of
[04:29] <wgrant>             (`IAccessArtifact`, grantee `IPerson`, grantor `IPerson`) triples
[04:29] <wgrant>             to grant.
[04:29] <wgrant>         """
[04:30] <StevenK> Right
[04:30] <StevenK> That pesky subscribed_by thing
[04:30] <wgrant> grantor
[06:01]  * StevenK blinks.
[06:02] <wgrant> StevenK: Hmm hmm?
[06:03] <StevenK>         # Only include subscribers who can see the bug, if it's private.
[06:03] <StevenK>         print list(indirect_subscribers)
[06:03] <StevenK>         if self.private:
[06:03] <StevenK>             print list(indirect_subscribers)
[06:03] <StevenK> [<Person at 0xf29fdd0 product-subscriber (Product-subscriber)>]
[06:03] <StevenK> []
[06:03] <wgrant> StevenK: It's probably a resultset
[06:03] <wgrant> Or some other sort of generator
[06:03] <wgrant> That you're consuming with the first list()
[06:03] <StevenK> It's a chain()
[06:03] <wgrant> Right, a generator
[06:04] <StevenK> Sigh, so I can't print it
[06:08] <StevenK> Bah, the query returns [], so it's fine, but product-subscriber is coming from somewhere.
[07:31] <wgrant> wallyworld: Did you consider precache_permission_for_objects?
[07:31] <wgrant> branchlisting.py uses it
[07:32] <wallyworld> yes but decided against it
[07:32] <wallyworld> since it's not the http caller needing to be cached
[07:32] <wallyworld> and it's exactly the same problem as for bug searching
[07:32] <wgrant> Isn't it?
[07:33] <wallyworld> ah, it is, yes
[07:33] <wgrant> Ah, you do it in BranchCollection, so this is a more general solution.
[07:33] <wallyworld> but i wanted to stick to the bug search pattern
[07:33] <wgrant> But you could equally do it in the view.
[07:33] <wgrant> Right.
[07:33] <wallyworld> i don't want to do it in the view
[07:33] <wallyworld> wrong place
[07:35] <wgrant> wallyworld: r=me, thanks
[07:35] <wallyworld> np, thanks for reviewing :-)
[07:35] <wallyworld> i really wanted to get that one sorted asap
[07:35] <wgrant> Yeah
[07:36] <wgrant> https://code.launchpad.net/~wgrant/launchpad/more-branchnamespace/+merge/114563 is pretty simple if you have a few mins.
[07:36] <wallyworld> sure
[07:37] <StevenK> wgrant: That does USERDATA, not PROPRIETARY
[07:38] <wallyworld> wgrant: 30	return False
[07:38] <wallyworld> should be return None i think
[07:38] <StevenK> I guess it will migrate when everything else does
[07:40] <wgrant> wallyworld: Good point. Doesn't actually matter, but it's wrong :)
[07:40] <wallyworld> wgrant: i agree with StevenK. we can cater for Proprietary in the if statement and it will work later
[07:40] <wallyworld> 42	+ if (information_type == InformationType.USERDATA and
[07:40] <wallyworld> 43	+ getFeatureFlag('disclosure.display_userdata_as_private.enabled')):
[07:40] <wallyworld> 44	+ return 'Private'
[07:40] <wallyworld> 45	+ return information_type.title
[07:40] <wallyworld> can add an == propprietary bit
[07:40] <wgrant> Where?
[07:41] <wgrant> That "return 'Private'" is just for the userdata_as_private
[07:41] <wallyworld> ah yes, sorry. misread it
[07:41] <wgrant> StevenK: Do you refer to getDefaultInformationType?
[07:41] <StevenK> That feature flag is getting used everywhere :-(
[07:41] <StevenK> wgrant: Yah
[07:42] <wgrant> StevenK: Well, the default information type is never proprietary yet
[07:42] <wgrant> So making it sometimes proprietary when it's never proprietary would be sort of wrong :)
[07:42] <wgrant> StevenK: I'll be adding a new feature-flagged codepath tomorrow which will return proprietary if the enum is set to return proprietary
[07:43] <StevenK> Ah
[07:43] <StevenK> wgrant: Yeah, you could use disclosure.proprietaryblahblah.disabled
[07:43] <wgrant> But returning proprietary before anything should be proprietary would seem to be a Bad Idea™
[07:43] <wgrant> StevenK: No
[07:43] <wgrant> disclosure.bvp_must_die or so
[07:44] <StevenK> Haha
[07:44] <StevenK> Curtis will be unhappy if you add another FF :-)
[07:44] <wallyworld> we can use the existing ff
[07:44] <StevenK> No, wgrant is right, we can't.
[07:44] <wgrant> We can't
[07:44] <wallyworld> disclosure.proprietary_information_type.disabled
[07:44] <wgrant> It's entirely different.
[07:45] <wgrant> This engages the BVP replacement
[07:45] <wgrant> Which we'll want to do before we enable proprietary
[07:45] <wallyworld> if the branch is associated with a proprietary project, shouldn't new branches be propprietary?
[07:45] <wgrant> Proprietary projects don't exist yet.
[07:45] <wallyworld> regardless / instead of bvp
[07:46] <wgrant> I suspect that a proprietary project has an enforced PROPRIETARY_ONLY branch config setting.
[07:46] <wallyworld> if a projject is has a current commercial subscription it can be
[07:46] <wallyworld> so i guess yes it may be too early
[07:46] <wgrant> Commercial subscriptions will enable the project owner to enable proprietary branches.
[07:47] <wgrant> They don't enforce all branches to be private.
[07:47] <wallyworld> wgrant: r=me, looks great
[07:48] <wgrant> Thanks
[07:48] <wallyworld> welcom
[07:49] <wgrant> The plan is to enable writable sharing RSN, then once that's out and working we can do the migration away from BVP to the new enumcol. The first stage of that work will still create User Data branches, like BVPs do now.
[07:49] <wgrant> Once BVP is dead, we can sensibly turn on Proprietary
[07:49] <wallyworld> ok
[07:49] <StevenK> wgrant: I guess we want IProject.default_propietary_branches
[07:49] <wgrant> At which point the BVP replacement can start doing Proprietary instead
[07:49] <wallyworld> so close yet so far
[07:49] <wgrant> StevenK: It's a four-state enum, remember.
[07:51] <wgrant> ‣ Public: Branches are public unless they contain sensitive security information.
[07:51] <wgrant> ‣ Public, can be private: New branches are public, but can be made proprietary later.
[07:51] <wgrant> ‣ Proprietary, can be public: New branches are proprietary, but can be made public later. Only people who can see the project's proprietary information can create new branches.
[07:51] <wgrant> ‣ Proprietary: Branches are always proprietary. Only people who can see the project's proprietary information can create new branches.
[07:51] <wgrant> Or so
[07:51] <StevenK> wgrant: Ah yes. I'm distracted by ACB
[08:28] <adeuring> good morning
[08:29] <czajkowski> morning
[08:33]  * cjwatson wonders if there's any chance of deploying up to r15608 today ...
[08:37] <jelmer> hi adeuring, czajkowski, cjwatson
[08:37] <adeuring> hi jelmer!
[08:38] <wgrant> cjwatson: We have no UK ops today, but jjo might be able to do it in a few hours if QA gets done
[08:43] <cjwatson> Yeah, I suppose I was hinting at those with pending QA :)
[08:43] <wgrant> StevenK, jcsackett ^^
[08:44] <wgrant> Ah, I think jcsackett might have done his, but forgotten one of the bugs
[08:44] <wgrant> So it's just StevenK, on something that doesn't really matter hugely at this point.
[08:51] <cjwatson> (That deployment would let me update all our documentation to refer to the API client and decommission the queue script, since the API is now feature-complete.)
[08:52] <wgrant> It would seem wise to keep the queue script around for a couple of weeks, just in case...
[08:52] <wgrant> Since we have no other way out.
[08:53] <cjwatson> Yeah, perhaps
[08:54] <cjwatson> I wonder if SRU handling is enough to stress-test things, or if we need a freeze period of quantal
[08:54] <cjwatson> The latter are a bit difficult to come by these days, since there's considerable top-down pressure not to freeze for alpha milestones
[08:54] <wgrant> I think routine SRU+security stuff is probably more likely to shake out issues than freezing a dev series.
[08:54] <wgrant> Freezes tend to often be handled through the web UI anyway, right?
[08:55] <cjwatson> Only because we felt we ought to and didn't have an API.
[08:56] <wgrant> Right, but they weren't traditionally done through queue
[08:56] <cjwatson> They've traditionally been a mix
[08:56] <wgrant> So removing queue is less likely to impact them.
[08:56] <wgrant> True
[08:57] <cjwatson> I'm not especially worried about routine NEW handling; the things I'm less sure about are timeouts on accepting uploads that close lots of bugs
[08:57] <cjwatson> Which are more likely in the development series, apart from kernel SRUs which happen through a PPA anyway so don't count
[08:58] <wgrant> Hm, indeed
[08:58] <wgrant> Perhaps we can accidentally freeze before the next unity upload...
[08:58] <cjwatson> I could certainly ask for an experimental freeze where we in fact just accept everything for a few days
[09:01] <cjwatson> And I've tweaked my pending announcement mail to remind people that I need to actually hear about bugs rather than quietly working around them
[09:01] <wgrant> :)
[09:59] <jtv> Hello jml!  Julian had an interesting suggestion: we found Launchpad's FakeMethod a tough thing to do without in MAAS, so maybe it would be an interesting thing to have in testtools?
[10:11] <jml> jtv: I've forgotten what FakeMethod does. Looking now.
[10:12] <jml> jtv: tbh, I think not. I think what you want is mfoord's mock: http://pypi.python.org/pypi/mock
[10:12] <jtv> jml: it's used for st/ubbing (mis-spelling to avoid bothering Stu) functions and methods.
[10:12] <jtv> Yes, this is a lot more lightweight.
[10:12] <jtv> \
[10:12] <jml> jtv: what does that mean?
[10:13] <jtv> It does a lot less.
[10:13] <jtv> It does:
[10:13] <jml> jtv: and that's a good thing?
[10:13] <jtv> Can be, if you don't want to climb the learning curve.
[10:14] <jtv> That was the problem with Mock when we first ran into it, I think: there was too much new stuff to take in, when all we really wanted is patch out some method to return a predetermined value, or raise a predetermined exception.
[10:14] <jml> it's pretty easy
[10:15] <jml> @patch("foo.bar")
[10:15] <jml> def f(mock_foo_bar):
[10:15] <jml>   mock_foo_bar.returnvalue = 42
[10:15] <jtv> Still:
[10:15] <jtv> self.patch(foo, "bar", FakeMethod(42))
[10:16] <jml> I riposte:
[10:16] <jml> self.patch(foo, 'bar', lambda *args: 42)
[10:16] <jtv> Don't forget the **kwargs.
[10:17] <jml> my test will fail if that matters :)
[10:17] <jtv> But sometimes we find that afterwards you want to know about what calls have been made to your fake, and that's also built into FakeMethod.  (Mock has something nicer for that, but again FakeMethod keeps it very simple)
[10:17] <jml> jtv: ok
[10:18] <jtv> Anyway, not trying to force it on you.
[10:18] <jml> jtv: No worries. I'm not interested in putting it into testtools. I would strongly suggest using mock and then having less code to maintain. Alternatively, create a library for FakeMethod.
[10:19] <jtv> Seems a bit silly to have something so small stand alone as a library… I think that's one reason why Julian suggested it might have a place in testtools.
[10:20] <jml> jtv: perhaps it might have a place in mock
[10:20] <jtv> What we did for now is just copy it.  Doesn't really matter if it diverges or not.
[10:20] <jml> well, maintaining way too much code _is_ the Launchpad Way.
[10:20] <jtv> :)
[10:20] <jml> no point in making your job too easy
[10:21] <jml> sorry. I shouldn't snark :(
[10:21] <jtv> That's okay… I can see the truth in it.
[10:21] <jtv> In this case, it's stable enough that I don't see it mattering much.  It's not like we ever find bugs in it.
[10:24] <jtv> We'd _like_ to have it in a shared place, of course, but it's not hugely important.  I think it'd probably fit poorly with Mock; maybe Mock has a good replacement for it.
[12:09] <cjwatson> OK, zope is melting my brain and I need some advice.  What might I have forgotten in http://paste.ubuntu.com/1087847/ that would cause "KeyError: 'editchroot'"?
[12:10] <cjwatson> It looks like it's failing to look up overview_menu.
[12:10] <cjwatson> But I might be misguessing as it's kind of hard to keep my head straight in 20-odd stack frames.
[12:12] <cjwatson> The expression it's trying to evaluate at the time is Expression: <PathExpr standard:u'overview_menu/editchroot/fmt:icon'>
[12:12] <cjwatson> And I think the menu is None.
[12:16] <jam1> hey jelmer, how's it going today?
[12:20] <cjwatson> http://paste.ubuntu.com/1087861/ is the full traceback I'm staring at.
[12:28] <cjwatson> Ah, maybe I have the NavigationMenu attached to the wrong interface
[12:30] <rick_h_> sorry cjwatson you're on my kryptonite
[12:30] <rick_h_> maybe adeuring knows a bit more
[12:32] <adeuring> cjwatson: right; without looking further I'd guess that overview_menu does not know about "editchroot"
[12:32] <jelmer> jam: hey
[12:33] <jelmer> jam: alright, reviewing and wrapped up the bzr upload to quantal
[12:33] <jelmer> jam: are you still working on the python2.7 transition?
[12:33] <mgz> with a ribbon?
[12:40] <rick_h_> sinzui: do you know where YUI comes from? It's in lp-sourcedeps and symlinked into the app root, but I can't figure out where that lp-sourcedeps directory came from
[12:40] <sinzui> I do not
[12:40] <sinzui> StevenK, do you know ^
[12:40] <wgrant> rick_h_: buildout
[12:40] <wgrant> rick_h_: There's a yui tarball in download-cache
[12:41] <wgrant> A buildout rule extracts it into yui/
[12:41] <rick_h_> is there? I was checking out and missed it
[12:41] <wgrant> Which is a symlink to lp-sourcedeps
[12:41] <rick_h_> ok, looking thanks
[12:41] <wgrant> $ ls download-cache/dist/yui-3.*
[12:41] <wgrant> download-cache/dist/yui-3.3.0.tar.gz  download-cache/dist/yui-3.3.tar.gz  download-cache/dist/yui-3.4.1.tar.gz  download-cache/dist/yui-3.5.0pr1.tar.gz
[12:41] <rick_h_> heh, lovely so just blind
[12:41] <rick_h_> oh heck, scrolling ftw thanks wgrant
[12:44] <wgrant> Heh
[12:46] <cjwatson> adeuring: mm, well, I now have http://paste.ubuntu.com/1087894/ which I think is less incorrect (it now actually has a NavigationMenu with usedfor = IDistroArchSeries), but I'm still getting exactly the same failure :(
[12:46] <cjwatson> queryAdapter(<a DAS object>, INavigationMenu, 'overview') -> None
[12:47] <wgrant> cjwatson: Have you registered it?
[12:47] <wgrant> You want the browser:menus ZCML directive
[12:48] <cjwatson> Ah, yes, I just got there by grepping for another case
[12:49] <cjwatson> Excellent!  Now I have a different failure, but a comprehensible one.  Thanks
[13:11] <rick_h_> abentley: http://blog.singly.com/2012/07/09/from-itch-to-scratched-google-hangout-permalink/
[13:12] <cjwatson> Is there a limit (practical or otherwise) to the size of file that can go in a multipart/form-data upload to LP?
[13:13] <abentley> rick_h_: Cool.  Sounds like what smoser did.
[13:28] <czajkowski> sinzui: good day. do you happen to know if ther eis a way to automate via a terminal milestones for a project ?
[13:28] <sinzui> czajkowski, do you mean create them, release them?
[13:29] <czajkowski> sinzui: https://answers.launchpad.net/launchpad/+question/202937
[13:29] <czajkowski> is why I am asking
[13:31] <sinzui> There  many launchpadlib scripts that do that
[13:31] <sinzui> https://launchpad.net/+apidoc/devel.html
[13:32] <sinzui> I have one that U use to release milestones, but nothing that creates the milestone, or adds a file to a project_release
[13:32]  * sinzui looks for example
[13:40] <sinzui> czajkowski, point the user to lp-project-upload in https://launchpad.net/ubuntu-dev-tools which will create a milestone, release it, then upload a file
[13:41] <czajkowski> sinzui: great, thank you/
[13:43] <sinzui> czajkowski, , actually, I don't see that script anymore
[13:43]  * sinzui looks for rename
[13:44] <Laney> it's probably in lptools now
[13:48] <sinzui> czajkowski, lp-project-upload moved to https://launchpad.net/lptools
[13:48] <czajkowski> sinzui: cheers
[13:59] <jam> jelmer: yes, I'm still working on the python2.7 stuff. I'm getting a segfault now in the lucid container, which is being problematic to track down.
[14:02] <mgz> a py2.7 specific segfault? because you had lucid vanilla working right?
[14:02] <jelmer> jam: do you have a gdb backtrace that's hinting at what might be happening?
[14:02] <rick_h_> jcsackett: ping, have a review for you if you get a sec. I *think* this is right and works locally but please sanity check me https://code.launchpad.net/~rharding/launchpad/lpyui-dep/+merge/114430
[14:03] <jam> jelmer: that's the best part, 'ulimit -c unlimited' and I can't find a core file
[14:03] <jam> mgz: yes
[14:03] <jam> jelmer: It fails while bootstrapping 'bin/py' I can at least run 'py -vv' and see that it is failing during "import code_..." ?
[14:03] <jam> however, just importing that module isn't enough to get it to crash
[14:04] <jam> I'm guessing there is something that is breaking the import machinery, or something along those lines.
[14:10] <jam> mgz, jelmer: I'm trying to do a fresh bootstrap (somehow, not sure if 'make clean' is actually clean enough)
[14:10] <jam> now that is weird...
[14:10] <jam> I did 'make schema' and it crashes at bin/py, but the outer OS seems to think gnome-screensaver just died
[14:11] <jelmer> hmm
[14:11] <jelmer> pid reuse?
[14:19] <jcsackett> rick_h_: it looks alright to me, but my Make/buildout knowledge is bare bones. i believe gary_poster has some expertise there iirc. if he has time, might be worth having him take a look too.
[14:20] <rick_h_> jcsackett: ok, I tested it out locally and tried to make sure make check/tests run, turning on/off the combo loader FF works, and then setting and unsetting the yui verison
[14:20] <jcsackett> rick_h_: given all that and a second pair of eyes, i think it's probably fine. if it's not, ec2 will choke on it anyway. so, like i said, r=me.
[14:20]  * jcsackett realizes he didn't actually say that.
[14:21] <gary_poster> jcsackett, hiya.  on calls. lemme know if you need me later
[14:22] <jcsackett> gary_poster: will do.
[14:28] <jam> jelmer: well this time it is crashing trying to import _ctypes which seems much more likely to be a problem.
[14:45] <jam> jelmer: so right now I'm trying to make sure it isn't re-using .pyc files or something along those lines, with the 2.6 install. But I accidentally nuked my download-cache and have to redownload it, etc.
[14:52] <jelmer> jam: fun :(
[14:52] <jelmer> jam: what did you have to do to get make to run, btw? for me it still fails (silently) during the mailman step
[14:53] <jam> jelmer: well right now 'make schema' is segfaulting, so I don't know that 'make' is working
[14:54] <jelmer> jam: have you tried "bzr grep python2.6" ?
[14:54] <jelmer> jam: I think one of the database scripts uses its own shebang line
[14:55] <jam> jelmer: bin/py was specifically segfaulting while running 'import site', so it is happening pretty early.
[14:55] <jelmer> ah, ok
[14:56] <mgz> jam: what's your recipe roughly? just add the lucid py2.7 ppa to a normal lucid setup of launchpad?
[14:57] <jam> mgz: and have a branch of launchpad that changes the PYTHON:= line in the makefile to not do crazy version checks, but just 'PYTHON:=python2.7'
[14:57] <jam> add-apt-repository ppa:pythoneers/lts
[14:57] <jam> then sudo apt-get install python2.7
[14:58] <mgz> ace. can probably repo here reasonably easily then, unless rocketfuel borks things too badly (then it's extra hacks in the branch)
[14:59] <jam> mgz: note that on startup I'm getting: http://paste.ubuntu.com/1088093/
[14:59] <jam> but everything was working with python-2.6, so I thought that was just noise
[15:01] <jam> I did run out of disk space at one point, and had to expose more space for the VM. maybe something got horrbly borked and I should just restart from scratch
[15:05] <mgz> fun.
[15:31] <czajkowski> jelmer: can you investigate please. https://support.one.ubuntu.com//Ticket/Display.html?id=19323
[15:32] <jelmer> czajkowski: on it
[15:33] <czajkowski> jelmer: thanks
[18:00] <abentley> jcsackett: Could you please review https://code.launchpad.net/~abentley/launchpad/mp-by-revision-id/+merge/114693 ?
[18:28] <jcsackett> abentley: r=me. looks good, and thanks--i've been wanting that to work. :-)
[18:29] <abentley> jcsackett: Thanks.  It'll also require some bzr-side fixing before lp-find-proposal can do it.
[18:37] <magcius> ev, ping
[22:00] <sinzui> jcsackett, wgrant, StevenK, wallyworld: http://people.canonical.com/~curtis/lp-milestone/report.html
[22:07] <lifeless> sinzui: did you do that yourself ?
[22:07] <lifeless> sinzui: or is it some stock tool we have hanging around ?
[22:07] <sinzui> Yes
[22:07] <lifeless> its nice
[22:08] <sinzui> I wrote it. It thinks it is talking to Lp, it is actually using json I pulled and removed private data
[22:08] <rick_h_> lifeless: replied in -dev for the combo loader notes. Let me knwo if there's something else I need to do.
[22:08] <sinzui> A lot could be reused in Lp or other tools
[22:09] <lifeless> sinzui: are the burn down charts totally LP sourced?
[22:10] <sinzui> yes
[22:10] <lifeless> sinzui: perhaps lpkanban would be a good place for the chart logic to live
[22:10] <sinzui> Most of the code is tested.
[22:10] <sinzui> I was thinking of pulling data from kanban, but I need s break from this report
[22:11] <lifeless> sinzui: lpkanban shows LP bug data for a team as a kanban board
[22:11] <lifeless> sinzui: its not leankitkanban related
[22:11] <lifeless> sinzui: and sure, not trying to give you work, just speculating about structure :)
[23:29] <StevenK> wgrant: http://pastebin.ubuntu.com/1088958/  test_add_comment_no_access fails since product-subscriber is in the list, but it should have no access to the bug, so WTF ...
[23:32] <wgrant> StevenK: That's pretty odd. Let me have a look
[23:39] <wgrant> StevenK: Oh
[23:39] <wgrant> StevenK: The return is a lie.
[23:40] <wgrant> getBugNotificationRecipients doesn't actually use the return value. It uses the contents of BugNotificationRecipients.
[23:40] <wgrant> So you need to filter what you add :(
[23:40] <wgrant> Or get BugNotificationRecipients to filter
[23:40] <StevenK> Oh, bleh
[23:40] <wgrant> Or *possibly* filter in getBugNotificationRecipients
[23:41] <StevenK> Let's teach BugNotificationRecipients how to filter
[23:43] <StevenK> Which looks ... fun
[23:46] <wgrant> StevenK: btw, qa?
[23:47] <StevenK> Oh, bleh.
[23:49] <rick_h_> ccccccbgjgvclbkvdbvchdknlnkhgutbkgbcurerrjvb
[23:49] <wgrant> I didn't know rick_h_ had a cat.
[23:52] <spm> possibly he's moving to Aus and this is the town he's moving to?
[23:52] <wgrant> True
[23:54] <StevenK> spm: That must be the short name.