| StevenK | cjwatson: I've approved the review, and the API script looks brilliant too. | 00:30 |
|---|---|---|
| cjwatson | Thanks. I reckon it ought to be possible to do setChroot(data=fileobj, sha1sum=foo), but life was a bit too short to get that done just now ... | 00:31 |
| cjwatson | That would make the progress bar a lot less painful. | 00:31 |
| StevenK | cjwatson: I'm also sure that one of us will take great joy in killing scripts/ftpmaster-tools/manage-chroot.py and related friends after your branch is deployed. | 00:33 |
| cjwatson | I have a branch locally for that :) | 00:34 |
| cjwatson | Though if you beat me to pushing, it's not like it's all that creative | 00:34 |
| cjwatson | And you probably deserve the LoC credit more :) | 00:35 |
| === cyclicflux is now known as Guest36460 | ||
| === Guest36460 is now known as CyclicFlux | ||
| StevenK | wgrant: I think your Zope upgrading has broken auditorfixture bootstrapping: http://pastebin.ubuntu.com/5797569/ | 05:44 |
| wgrant | StevenK: Except I didn't touch auditorfixture | 05:48 |
| wgrant | Was it not pinned? | 05:48 |
| wgrant | That zc.recipe.egg constraint is suspiciously high | 05:49 |
| wgrant | I'm pretty sure LP still uses 1.x | 05:49 |
| wgrant | ztk-versions.cfg:zc.recipe.egg = 1.3.2 | 05:49 |
| StevenK | wgrant: Hm, it needs a versions.cfg? | 05:50 |
| wgrant | StevenK: Might be advisable. It possibly picked up buildout 2 if I left that in download-cache | 05:50 |
| wgrant | Or just specify an appropriate version constraint in setup.py | 05:50 |
| wgrant | Pinning is probably less useful | 05:50 |
| wgrant | You need to work out where that zc.recipe.egg > 2.0a3 constraint came from | 05:51 |
| StevenK | wgrant: Reverting to the bootstrap.py in the tree: http://pastebin.ubuntu.com/5797584/ | 05:53 |
| wgrant | Right, you need to restrict your zc.buildout version | 05:53 |
| wgrant | $(SHHH) PYTHONPATH= $(PYTHON) bootstrap.py\ | 05:53 |
| wgrant | --setup-source=ez_setup.py \ | 05:53 |
| wgrant | --download-base=download-cache/dist --eggs=eggs \ | 05:53 |
| wgrant | --version=1.7.1 | 05:53 |
| wgrant | That's how LP invokes it | 05:54 |
| StevenK | Error: There is a version conflict. | 05:56 |
| StevenK | We already have: zc.buildout 1.7.1 | 05:56 |
| StevenK | but z3c.recipe.tag 0.7 requires 'zc.buildout>=2.0'. | 05:56 |
| StevenK | Guess I need to clean harder | 05:57 |
| StevenK | Hm, that doesn't help, but I can't see what is pulling in z3c.recipe.tag 0.7 | 06:04 |
| wgrant | StevenK: It will probably be trying to pick the latest version it can find | 06:08 |
| StevenK | Oh, there is a 0.7 in download-cache | 06:10 |
| StevenK | wgrant: Hmm, adding 'z3c.recipe.tag == 0.6', to setup.py in install_requires still has it grabbing 0.7 | 06:16 |
| wgrant | StevenK: I don't know how well that will work. It may need to be versions.cfg | 06:17 |
| StevenK | % cat versions.cfg | 06:21 |
| StevenK | [versions] | 06:21 |
| StevenK | z3c.recipe.tag = 0.6 | 06:21 |
| StevenK | ... | 06:21 |
| StevenK | Getting distribution for 'z3c.recipe.tag'. | 06:21 |
| StevenK | Got z3c.recipe.tag 0.7. | 06:21 |
| * StevenK stabs buildout | 06:21 | |
| wgrant | Is versions.cfg being used? | 06:21 |
| wgrant | And are you sure there are no other version dependencies that are pulling in z3c.recipe.tag? | 06:21 |
| StevenK | Stop being obstreperous, damn it! | 06:21 |
| StevenK | wgrant: How do I check that? | 06:21 |
| wgrant | -vv? | 06:22 |
| StevenK | wgrant: Oh, it's direct, due to the buildout.cfg target [tags] | 06:28 |
| wgrant | Sure, there's a direct dep | 06:31 |
| wgrant | But your versions.cfg, if you've actually mentioned in buildout.cfg, should pin it to the right version | 06:32 |
| wgrant | Unless some other dep wants 0.7 | 06:32 |
| StevenK | Oh, doh | 06:33 |
| === tasdomas_afk is now known as tasdomas | ||
| StevenK | cjwatson: I accidently manage-chroot.py. But removeChroot() is on prod. | 10:59 |
| cjwatson | I noticed, thanks | 10:59 |
| ttx | The Launchpad testr run takes a looong time. What would be the proper syntax to run only lib/lp/blueprints/tests/test_webservice.py ? I'm fumbling the -t PATTERN apparently | 13:35 |
| cjwatson | bin/test -vvct lp.blueprints.tests.test_webservice | 13:36 |
| ttx | cjwatson: are you on the Launchpad team those days or what ? :) | 13:36 |
| ttx | cjohnston: thx | 13:36 |
| ttx | oops | 13:36 |
| ttx | cjwatson: thx | 13:36 |
| cjwatson | not really, just an interested onlooker who sometimes finds it quicker to fix his own bugs :) | 13:36 |
| cjwatson | though I suppose https://dev.launchpad.net/Contributions might belie that slightly | 13:37 |
| === wedgwood_away is now known as wedgwood | ||
| ttx | Hmm... Looks like I could use some help. I'm working on exposing proposeGoal/acceptGoal/declineGoal methods in the specification API | 14:46 |
| ttx | I think I got the implementation right but i'm strugging with unit tests | 14:46 |
| ttx | See https://code.launchpad.net/~ttx/launchpad/lp1193389 | 14:46 |
| ttx | spec.proposeGoal(goal=series) in the tests fails with 401 Unauthorized | 14:47 |
| ttx | ('goalstatus', <Specification 13 u'name-100429' for u'product-name-100423'>) | 14:47 |
| === joeyfreenode is now known as joey | ||
| ttx | It feels like it doesn't like that the proposer (or driver) plays with goalstatus through proposeGoal(). | 14:49 |
| cjwatson | I think you need to move those methods to a new ISpecificationDriver interface and declare that as requiring launchpad.Driver | 14:53 |
| cjwatson | I think you need to move those methods to a new ISpecificationDriver interface and declare that as requiring launchpad.Driver | 14:53 |
| xnox | udd import script getting 401 from launchpad. Are "natty" branches frozen or something? | 14:53 |
| xnox | http://package-import.ubuntu.com/status/eglibc.html#2013-06-25 06:22:30.579024 | 14:53 |
| cjwatson | At the moment they only seem to be protected by browser code | 14:53 |
| xnox | http://package-import.ubuntu.com/status/eglibc.html | 14:53 |
| cjwatson | Also there's nothing in lib/lp/blueprints/configure.zcml that declares permissions on goalstatus, so it'll default to closed | 14:54 |
| cjwatson | There's a comment about that though, but a strange one; goalstatus' security is going to be checked even if it's set via proposeGoal etc. | 14:55 |
| cjwatson | You may need somebody more expert than me to look at this | 14:55 |
| ttx | cjwatson: yeah, the model around series goal is a bit weird. | 14:56 |
| cjwatson | Well, never mind model, the permissions seem mad | 14:56 |
| cjwatson | Which suggests to me I don't fully understand what's going on | 14:57 |
| ttx | there is also a comment in .zcml : "NB: goals and goalstatus are not to be set directly, it should only be set through the proposeGoal / acceptBy / declineBy methods"... so you'd think the method access control should be enough | 14:57 |
| cjwatson | that was what I referred to above | 14:57 |
| cjwatson | 15:55 <cjwatson> There's a comment about that though, but a strange one; goalstatus' security is going to be checked even if it's set via proposeGoal etc. | 14:57 |
| cjwatson | simply going through a call to .proposeGoal is not enough to magically strip access control off zope attribute access | 14:58 |
| ttx | cjwatson: ok | 14:58 |
| cjwatson | but that means I don't understand exactly why it's failing for you right now, because my argument is that this is dangerously open at the moment :) | 14:59 |
| cjwatson | I do think that the permissions on browser methods should be carefully unified with those on the underlying interfaces as a prerequisite to exporting things over the API. Why the test is failing, not entirely sure | 14:59 |
| === BradCrittenden is now known as bac | ||
| cjwatson | Or, rather, I think I understand why it's failing but I then don't understand why the normal browser view code works | 15:01 |
| cjwatson | It doesn't seem to be doing removeSecurityProxy or anything nasty like that | 15:02 |
| ttx | Yeah. unfortunately we are quickly approaching the end of the timebox I can dedicate to fumbling my way through launchpad code... so let's see if someone can shine some light on this... otherwise i'll probably work around the missing feature from browser rather than API | 15:06 |
| cjwatson | wgrant or StevenK should be able to answer when they show up | 15:11 |
| cjwatson | Your change looks structurally roughly right to me, FWIW, it's just the legacy permissions weirdness ... | 15:11 |
| ttx | cjwatson: heh, so close and yet so far :) | 15:20 |
| === micahg_ is now known as micahg | ||
| === tasdomas is now known as tasdomas_afk | ||
| === dpm is now known as dpm-afk | ||
| === heroux_ is now known as heroux | ||
| === tasdomas_afk is now known as tasdomas | ||
| === jelmer_ is now known as jelmer | ||
| === tasdomas is now known as tasdomas_afk | ||
| === wedgwood is now known as Guest19180 | ||
| === Guest19180 is now known as wedgwood | ||
| === wedgwood is now known as wedgwood_away | ||
| wgrant | ttx, cjwatson: Managed to get a traceback out of that branch. It's lp.blueprints.subscribers.specification_goalstatus assuming that it will always get an unproxied object. I don't think that subscriber is ever actually used normally, since it's only triggered when distroseries or productseries on the spec change, and the only view that does that is SpecificationGoalProposeView, which doesn't call updateContextFromData, so doesn't fire an ... | 23:17 |
| wgrant | ... ObjectModifiedEvent. | 23:17 |
| wgrant | The model code seems to handle the goalstatus transitions correctly; I suspect you could just drop that subscriber entirely, since it's clearly broken | 23:17 |
| wgrant | Some of that subscriber still shows sabdfl in annotate, so it hasn't been touched in a while :) | 23:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!