| xnox | barry: the latest & greatest way is via lxc container these days =) | 01:15 |
|---|---|---|
| wgrant | https://dev.launchpad.net/Running/LXC | 01:15 |
| wgrant | But which branch? | 01:15 |
| xnox | barry: see launchpad dev wiki. I had it running in the container quite quickly without destroying anything. | 01:15 |
| xnox | wgrant: the one were i add support for header auth on the +access-page. | 01:16 |
| wgrant | Oh, right. | 01:16 |
| xnox | lp:~xnox/launchpad/devel or some such | 01:16 |
| wgrant | Yeah, worst branch name ever :) | 01:16 |
| xnox | wgrant: well i had a normal one, but after the whole branch setup machinery it started to force devel name for me. | 01:17 |
| xnox | wgrant: anyway, for some reason just by changing the form to either be from headers or from body, results in request token to getting self destroyed when going via header auth. | 01:18 |
| xnox | thus one can exchange it multiple times.... which is bad. | 01:18 |
| wgrant | xnox: Perhaps the transaction is not being committed in some cases? | 01:19 |
| wgrant | I'd turn on full statement logging in postgresql.conf to see what's going on. | 01:19 |
| xnox | interesting. i'll explore that. is there a way to enforce committing transaction either in the view code or in the "story" document? | 01:22 |
| wgrant | A POST should always be committed unless it crashes. | 01:23 |
| xnox | i see. i do wonder if it is crashing. | 08:31 |
| cjwatson | wgrant: Your livefs copy_field/export_factory_operation comment about my error in IPersonViewRestricted.createLiveFS: wouldn't doing either of those entail importing ILiveFS into lp.registry.interfaces.person, which is probably suboptimal? | 09:38 |
| wgrant | cjwatson: That's a good point. You could use contributes_to, or better still use something like lp.livefses.new | 09:39 |
| wgrant | We should avoid bloating IPerson even if it doesn't require layer-violating imports. | 09:39 |
| cjwatson | Mm, right | 09:41 |
| wgrant | Also, I've realised it's probably a terrible idea to allow random people to request builds of someone's LiveFS. It means a build is half owned by the requester, half by the LiveFS owner, and half by the archive owner. | 09:45 |
| wgrant | Requiring that the requester must be able to operate on behalf of the LiveFS owner solves most of that problem, as the only impact the archive owner can have is deleting their PPA. | 09:46 |
| Kagetsuki | hello, I'm trying to set up a PPA and I'm a little confused on some things. First off I have a github repository which builds two debs with cmake - a lib and a command line client. Is there some way to specify this in the control file? should I have two control files? should I have two debian directories? | 09:46 |
| wgrant | If we eventually open up builds to the world, we probably want some way to easily clone LiveFSes. But the free-for-all nature of projects and recipes isn't ideal, and we can easily avoid introducing the same problems here. | 09:47 |
| cjwatson | The use case I was thinking of was somebody in the touch team requesting a build of one of their LiveFSes against a particular PPA, without them having to be authorised to build the primary ones. | 09:47 |
| wgrant | Kagetsuki: This channel is for the development of the code that runs Launchpad.net. You probably want #ubuntu-packaging. | 09:47 |
| cjwatson | Perhaps being able to copy a LiveFS easily is better, indeed. | 09:47 |
| wgrant | cjwatson: Yeah, I see the use cases. | 09:47 |
| Kagetsuki | @wgrant OH! Sorry! Keep up the awesome work! | 09:47 |
| cjwatson | (For the time being that could be an API script without much trouble.) | 09:48 |
| wgrant | Exactly. | 09:48 |
| wgrant | The consumers are so few early on that we can see what happens. | 09:48 |
| wgrant | And if it doesn't work out, we can find some way to relax the restriction without introducing the foreseen problems. | 09:49 |
| wgrant | But it's difficult to reign it in later. | 09:49 |
| wgrant | rein | 09:49 |
| wgrant | Given that you haven't implemented authorisation yet, I guess the main change this yields is that the paths become something like /~ubuntu-cdimage/+livefs/ubuntu/utopic/desktop/+build/1234, rather than /ubuntu/+archive/primary/+livefsbuild/1234. | 09:53 |
| cjwatson | That's better anyway. | 09:54 |
| wgrant | Yeah. | 09:54 |
| cjwatson | Well. Somebody in ~ubuntu-cdimage (say) could still in theory request a build for a different PPA | 09:55 |
| wgrant | They could, yes. | 09:55 |
| cjwatson | But maybe that's not worth supporting | 09:55 |
| wgrant | Why is that a problem? | 09:55 |
| cjwatson | The per-archive URLs would still make sense in that case | 09:55 |
| cjwatson | If we're relying on LiveFS copying to support the touch use cases, I wonder if we shouldn't fold a bunch of stuff from LiveFSBuild back into LiveFS | 09:56 |
| wgrant | LiveFSBuild has to have archive on either way, it's mostly a matter of whether requestBuild takes the arg or not. | 09:56 |
| cjwatson | Though I think we still want to have the same LiveFS for a pre-release build against the release pocket and a post-release build against -proposed | 09:57 |
| wgrant | Hm, I guess it doesn't have to, actually, if we decide that LiveFSBuilds are solely owned by the LiveFS owner. | 09:57 |
| wgrant | Right, we should support that. That's a common case that doesn't cross any trust boundaries. | 09:57 |
| wgrant | Changing the archive also doesn't really cross any trust boundaries. It's mostly a matter of whether we want to support it. | 09:57 |
| cjwatson | And of course the DAS should still be on LiveFSBuild. | 09:57 |
| wgrant | I believe the only thing in question is Archive. | 09:58 |
| cjwatson | So I guess we don't gain much, because LiveFS would still be a partial specification. | 09:58 |
| cjwatson | I would like to avoid the whole question of how privacy of livefs vs. archive owner interact, if possible. | 09:58 |
| cjwatson | So saying that if you want a different archive then you must copy the livefs is somewhat appealing. | 09:59 |
| wgrant | That problem will always exist. We just have to minimise the impact. | 09:59 |
| wgrant | The LiveFS owner could lose access to the P3A either way. | 09:59 |
| cjwatson | Oh, and other members of the LiveFS-owning team might not be able to see a private Archive even if the member of the team who created the LiveFS can. | 10:00 |
| wgrant | Having LiveFSBuilds live in a hierarchy under the LiveFS means that the owner could still traverse to them, they just wouldn't be able to see the archive field. | 10:00 |
| cjwatson | Yeah. In that case I'm inclined to leave the DB layout the way it is | 10:00 |
| wgrant | The only way you could totally avoid it is by requiring archive.owner == livefs.owner, which isn't going to happen | 10:01 |
| cjwatson | Being able to request a build into some other archive is convenient for one-off tests | 10:01 |
| cjwatson | Sorry, I should stop saying into | 10:01 |
| cjwatson | against some other archive | 10:01 |
| wgrant | Right, I think the only change we want from the old design is that the LiveFSBuild requester must participate in the LiveFS owner at the time of the request. | 10:01 |
| cjwatson | And the hierarchy change | 10:02 |
| wgrant | Er yes, that too. | 10:02 |
| cjwatson | Sounds doable then. | 10:03 |
| cjwatson | /livefses is a messy plural, but whatever | 10:05 |
| wgrant | Indeed, and it's unfortunate having a collection with one method, but it's better than having every create method ever on IPerson or IProduct. Really makes things difficult to understand, with all the layering violations. | 10:06 |
| barry | xnox: cool. i have a few other things to do this morning, but will take another look later today | 13:03 |
| cjwatson | wgrant: FWIW I've thought about it and I think we have to keep LiveFSBuilds against private Archives themselves private. Otherwise you can run a livefsbuild of your choice against a private archive and find out what's in it even after you've lost access to it. And if you don't have access to the archive then none of the artifacts on livefsbuild are going to be any use to you, so there isn't much point in being able to traverse to it ... | 13:38 |
| cjwatson | ... either. | 13:39 |
| wgrant | Yeah, I realised that a couple of hours ago as well. | 13:39 |
| cjwatson | Ugh, the build system isn't happy with this /livefses top-level collection | 14:33 |
| wgrant | cjwatson: Oh, howso? | 14:33 |
| cjwatson | http://paste.ubuntu.com/7404885/ | 14:33 |
| cjwatson | Something to do with there being no non-devel methods, maybe? | 14:34 |
| cjwatson | The traceback is not wholly transparent | 14:34 |
| wgrant | Yeah, TALES is great. Suppresses everything into a LocationError. | 14:34 |
| wgrant | Try exporting LiveFS and LiveFSBuild on >=beta, rather than >=devel | 14:34 |
| cjwatson | Ah, https://bugs.launchpad.net/lazr.restful/+bug/760849 | 14:37 |
| _mup_ | Bug #760849: No way to restrict export_as_webservice_collection to a given API version <api> <lazr.restful:Triaged> <https://launchpad.net/bugs/760849> | 14:37 |
| wgrant | Ah, yeah, I remember that now. | 14:39 |
| cjwatson | wgrant: Thanks, better now. | 15:00 |
| === marcoceppi_ is now known as marcoceppi | ||
| cjwatson | xnox: devel> rocketfuel-{setup,get} etc. force devel for the main LP devel branch, but you aren't expected to work there; you're expected to "bzr branch devel some-proper-name" and do your work in there. | 18:24 |
| cjwatson | (And run "utilities/link-external-sourcecode && make" in the new branch in an appropriate container.) | 18:27 |
| xnox | ok. | 18:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!