| rockstar | It's not been happiness. | 00:00 |
|---|---|---|
| sinzui | rockstar, you just need a breadcrumb adapter, but since you are messing with the hierarchy, I think my many title-like examples do not help | 00:01 |
| rockstar | sinzui, I don't specifically NEED to mess with hierarchy, but I didn't see another way. | 00:01 |
| rockstar | If you have a better way, I are happy to hab it. | 00:01 |
| * rockstar has a mushy brain before lunch time | 00:02 | |
| sinzui | rockstar, I cannot find the hack I did for team membership. It has two parents based on context, and I used a breadcrumb adapter for it. The test is not in the registry/browser/test_breadcrumbs as I recall | 00:03 |
| rockstar | sinzui, ah, two parents would be perfect. I already have a working breadcrumb that will do this. | 00:04 |
| rockstar | sinzui, where's that adapter at? | 00:13 |
| sinzui | rockstar, there are many. I am looking for one that change more than the text | 00:13 |
| rockstar | sinzui, I need to change the text and the url basically. | 00:15 |
| sinzui | rockstar, look at registry/browser/milestone and ./tests/test_breadcrumbs for MilestoneBreadcrumb | 00:17 |
| sinzui | that will get you started while I look for a glorious hack | 00:17 |
| rockstar | sinzui, yeah, I was on my way to a glorious(ly bad) hack when I pinged you. :) | 00:18 |
| rockstar | I suspected it would require something hacky. | 00:18 |
| rockstar | sinzui, I don't see anything in milestone.py that would affect breadcrumbs | 00:24 |
| sinzui | rockstar, MilestoneBreadcrumb defines the text and you can redefine the url property | 00:25 |
| sinzui | rockstar, to change the order or items in the breadcrumb, you need to hack Hierarchy.objects in a subclass that is registered for the recipe. The default object are those that are traversed. you want to mutate self.request.traversed_objects or consider monkeying with .items to mutate one of the breadcrumbs | 00:30 |
| rockstar | sinzui, ah, okay. It looks like I was already on that track then. | 00:32 |
| sinzui | BranchHierarchy is the only good example I know of | 00:33 |
| sinzui | The teammembership issue was solved indirectly by the fact the views are ancient and I could hack the class the provide breadcrumb info | 00:34 |
| sinzui | Edwin-lunch, ping | 00:36 |
| === Edwin-lunch is now known as EdwinGrubbs | ||
| EdwinGrubbs | sinzui: hi | 00:36 |
| sinzui | EdwinGrubbs, I do not think setPrefered email address should create an account. | 00:37 |
| sinzui | EdwinGrubbs, I do not think it should change an account | 00:38 |
| sinzui | EdwinGrubbs, It may need to check that the email address has the account *and* person we expect. Consider if we are setting the person email address and the account is missing, we could add that (but I do not know of a case where this is a real issue) | 00:39 |
| EdwinGrubbs | sinzui: do you mean you don't think createPersonAndEmail() should activate an account? I'm already removing that functionality from setPreferredEmail. | 00:39 |
| sinzui | EdwinGrubbs, right no changing the account | 00:40 |
| sinzui | EdwinGrubbs, I think there is a test that says it should doc/account? | 00:40 |
| sinzui | EdwinGrubbs, That test predates SSO | 00:40 |
| EdwinGrubbs | ok\ | 00:40 |
| abentley | wgrant, it appears that I cannot pass archives as parameters into a launchpadlib request, due to some evil with a RedirectionView. Have you encountered this? | 00:48 |
| abentley | wgrant, similarly, calling launchpad.load on a PPA's URL leads to infinite redirects. | 00:50 |
| gary_poster | mwhudson: back for a sec. errors in site-customize (and site.py) are swallowed generally in Python IIRC--that's what you are encountering in that regard. | 01:19 |
| gary_poster | And no, there is not a way to register something for a class and all subclasses. The only mechanism right now would be for you to do the registration yourself, iterating over the subclasses. | 01:19 |
| gary_poster | A way to get somewhat similar effect but in a way that is a bit ugly is monkeypatch the root class you care about and say "__Security_checker__ = DummyChecker()" and define DummyChecker as something that allows all names with the zope.security.CheckerPublic permission. That would mean that things were still proxied but they'd allow access very quickly. | 01:19 |
| gary_poster | Alternatively...we're in "propose a change to zope.security" land, which I'd be happy to help with, but would require the usual extra care for use cases that are not your own, and coding and social energy that might not pan out. | 01:19 |
| mwhudson | gary_poster: registering all subclasses seems to work for me for now | 01:33 |
| mwhudson | gary_poster: thanks for the follow up | 01:33 |
| gary_poster | cool | 01:38 |
| gary_poster | night all | 01:44 |
| cody-somerville | Where does registry keep its tests for webservice API stuff? I don't see anything in lib/lp/registry/doc/product.txt for example. | 02:56 |
| mwhudson | cody-somerville: it might be lib/lp/stories/webservice | 02:57 |
| mwhudson | uh | 02:57 |
| sinzui | stories/webservice/project-registry.txt | 02:57 |
| mwhudson | with registry in there | 02:57 |
| sinzui | ^ cody-somerville stories/webservice/project-registry.txt | 02:57 |
| sinzui | I still need to find a sane location for api tests | 02:58 |
| cody-somerville | sinzui, Should I export newSeries as new_series or newSeries? I notice newProject is exported as new_project and addFile as add_file but getSeries is exported as getSeries. | 03:00 |
| sinzui | cody-somerville, I think new_series is right. | 03:02 |
| cody-somerville | sinzui, Should I test new_series as extensively as new_project? | 03:02 |
| sinzui | I think we need to verify only that it can be accessed using the correct permission and that a series was created. Any other test would duplicate the model teasts | 03:03 |
| sinzui | tests | 03:03 |
| cody-somerville | sinzui, FYI add_file doesn't seem to be tested for correct permissions | 03:14 |
| sinzui | cody-somerville, I may not have been clear... | 03:14 |
| sinzui | cody-somerville, permissions are defined else where for the web but the api commonly exposes items that are not in the web... | 03:15 |
| cody-somerville | sinzui, ah, you only want me to test that it can be used with the correct permission, not that it can't be used with incorrect permissions | 03:16 |
| cody-somerville | But considering that incident with the soyuz API, doesn't it make sense to test? | 03:16 |
| sinzui | so if *anyone* can see the method/data, then use the anon helper, other login as the correct user and verify the driver can create a series. | 03:16 |
| sinzui | I do not think testing something twice is good. I still want to run the tests on my computer in less than 30 minutes. | 03:17 |
| * persia is a big fan of both positive and negative tests related to authorisation | 03:17 | |
| sinzui | cody-somerville, test a driver and some other user to verify only the person that needs to access that method can | 03:18 |
| cody-somerville | I'm confused. Do you want me to test permission or not? :P | 03:21 |
| sinzui | I have a lot of confidence that newSeries sane permissions. I care that a project driver can create a series. Testing that someone else cannot can be done, but I think that would be testing a lazr.restful failure, not a zcml or developer failure | 03:23 |
| cody-somerville | sinzui, hmmm... looking at the apidoc, new_series looks out of place compared to all the other post methods on Project. | 03:32 |
| sinzui | The posts use methods names: newSeries? | 03:33 |
| cody-somerville | sinzui, looking through the API doc, most methods are camelCase | 03:33 |
| sinzui | Then I think camelCase is nicest for users. | 03:34 |
| cody-somerville | I agree. | 03:34 |
| cody-somerville | sinzui, https://code.edge.launchpad.net/~cody-somerville/launchpad/export-newSeries-via-api/+merge/23978 | 04:08 |
| sinzui | cody-somerville, r=me. short and to the point. Do you want me to land this now? | 04:10 |
| thumper | rockstar: replace -- breadcrumb = queryAdapter(obj, IBreadcrumb) | 04:21 |
| thumper | with | 04:21 |
| thumper | breadcrumb = IBreadcrumb(obj, None) | 04:21 |
| thumper | sinzui: did you write breadcrumbs? | 04:22 |
| sinzui | salgado did | 04:22 |
| thumper | sinzui: ok, do you agree with the above replacement? | 04:23 |
| sinzui | thumper, yes. i agree | 04:24 |
| jtv1 | wgrant: heya! I ran a first test of our buildfarm jobs. | 05:55 |
| === jtv1 is now known as jtv | ||
| mwhudson | bug 352800 | 06:12 |
| cody-somerville | sinzui, I can land it myself but you're welcome to if you'd like. | 07:07 |
| cody-somerville | sinzui, landing | 07:09 |
| wgrant | jtv: How did it go? | 08:07 |
| jtv | wgrant: ran into a known buildmaster/soyuz bug. | 08:07 |
| jtv | bug 496574 | 08:08 |
| mup | Bug #496574: buildd-manager fails to deal with "Fault 8002" errors <buildd-manager> <soyuz-build> <Soyuz:Triaged> <https://launchpad.net/bugs/496574> | 08:08 |
| jtv | Of course that means the build still failed; probably a matter of getting the firewall settings right | 08:08 |
| wgrant | jtv: Yes, but what caused the slave fault? | 08:08 |
| wgrant | Ah, right. | 08:08 |
| jtv | wayyy ahead of you | 08:08 |
| wgrant | You sure it was actually a job failure? There was nothing else in the buildd-manager logs? | 08:09 |
| adeuring | good morning | 08:10 |
| wgrant | Whenever mine failed I got a more descriptive traceback. | 08:10 |
| bigjools | wgrant: what's wrong with having bzr-builder in the chroots? | 08:36 |
| wgrant | bigjools: It pulls in a whole tonne of crap on top of the minimal buildd environment, which will probably cause some builds to not work properly, and others to work when they should not. | 08:37 |
| bigjools | wgrant: what crap, exactly? | 08:37 |
| wgrant | bigjools: bzr-builder, bzr, lots of Python... | 08:38 |
| bigjools | sigh | 08:38 |
| wgrant | Stuff which is not Build-Essential, so has no business being in our minimal chroots. | 08:38 |
| bigjools | wgrant: having it in a PPA is crack | 08:38 |
| wgrant | bigjools: Why? | 08:39 |
| bigjools | we need a new chroot for daily builds | 08:39 |
| bigjools | because it's more shit to maintain | 08:39 |
| wgrant | Maintain two packages in a PPA, or maintain 6 new chroots... | 08:39 |
| wgrant | (chroots that need that PPA anyway) | 08:40 |
| bigjools | huh? one will suffice for daily build chroots | 08:40 |
| bigjools | they'll be i386 | 08:40 |
| wgrant | * many series | 08:40 |
| bigjools | lucid only? | 08:41 |
| bigjools | or maverick only | 08:41 |
| wgrant | Why? | 08:41 |
| bigjools | this is for crack-of-the day, which is on the dev release | 08:41 |
| wgrant | Didn't someone just implement multi-series support a couple of weeks ago? | 08:42 |
| bigjools | anyway, even if we did 6 more chroots I don't see what the big deal is | 08:42 |
| wgrant | All, crack-of-the-day isn't only the dev release, is it? | 08:42 |
| wgrant | bigjools: Where do those chroots get their packages? | 08:42 |
| wgrant | A PPA, probably. | 08:42 |
| wgrant | So a PPA has to be maintained anyway. | 08:43 |
| bigjools | ?! | 08:43 |
| bigjools | the package would be installed in the chroot | 08:43 |
| wgrant | Yes. | 08:43 |
| wgrant | But what builds the package? | 08:43 |
| mrevell | Howdy | 09:05 |
| maxb | What's wrong with having bzr-builder in a PPA and installing it on every build? That's exactly analogous to an existing package build. | 09:06 |
| wgrant | Exactly my point. | 09:08 |
| bigjools | there are 2 issues, not necessarily problems but things to think about: | 09:14 |
| bigjools | 1. it's slower to do that | 09:14 |
| bigjools | 2. it's another external dependency to maintain, which can go wrong and block builds | 09:15 |
| bigjools | if the IS people who will run it decide that it's ok to do that, then I don't mind | 09:15 |
| bigjools | ultimately they will decide | 09:16 |
| bigjools | but I want to consider all options before diving into the first one we think of | 09:16 |
| jml | good morning | 09:32 |
| jml | you know #haskell gets a lot of traffic | 09:32 |
| === almaisan-away is now known as al-maisan | ||
| mrevell | Hey noodles775, can I bug you again about that underline on the help images? | 09:46 |
| noodles775 | mrevell: sure | 09:51 |
| noodles775 | Can anyone point me to where I can read about supporting different API versions? It's not at https://dev.launchpad.net/API/ImplementingAPIs | 10:42 |
| * noodles775 reads the source in the meantime. | 10:42 | |
| * noodles775 finds lazr/restful/example/multiversion | 10:46 | |
| === al-maisan is now known as almaisan-away | ||
| didrocks | jml: can you think we can have someone on the Launchpad side for this spec (https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-quickly), to speak about proper way for gpg/ssh upload | 11:25 |
| === almaisan-away is now known as al-maisan | ||
| === mrevell is now known as mrevellunch | ||
| === matsubara-afk is now known as matsubara | ||
| jml | didrocks: by "spec" you really mean UDS discussion session, right? | 13:41 |
| didrocks | jml: right | 13:41 |
| === al-maisan is now known as almaisan-away | ||
| jml | didrocks: yeah. It's possible that the right people to speak on the topic aren't going to be at UDS | 13:41 |
| didrocks | jml: oh, you told me the contrary when we saw the gpg/ssh issue :/ do you think there could be a way to advance on the subject? | 13:42 |
| jml | didrocks: we can get them in remotely | 13:42 |
| didrocks | jml: otherwise, I'll do the ugly hack as groundcontrol do with screenscrapping | 13:42 |
| didrocks | that's the easy solution, but well :/ | 13:43 |
| jml | didrocks: I'll ask around. | 13:43 |
| didrocks | thanks :) | 13:43 |
| jml | didrocks: do you remember the bug report about all of this | 13:45 |
| didrocks | jml: I guess the gpg and ssh key were closed, even if not 100% feature-full (only the consultation part is achieved) | 13:45 |
| jml | didrocks: still, the bug would be helpful | 13:46 |
| didrocks | jml: do I create one for ssh, one for gpg? | 13:47 |
| jml | didrocks: you mean there aren't bugs already? sure, one for each please. | 13:48 |
| didrocks | jml: I can reopen the old bug, but they were closed one we pushed the read branches | 13:48 |
| didrocks | jml: will do, one sec | 13:48 |
| jml | didrocks: I think we might also need to have a separate discussion at UDS regarding bug 532055 | 13:50 |
| mup | Bug #532055: Provide a user-friendly way of authorizing desktop, GUI launchpadlib applications <launchpadlib :Triaged> <https://launchpad.net/bugs/532055> | 13:50 |
| didrocks | jml: that would be great | 13:52 |
| === mrevellunch is now known as mrevell | ||
| jml | didrocks, emphasis on _separate_ | 13:54 |
| didrocks | jml: yeah, that's a big discussion ;) Ok, filed bug #568981 and bug #568982 | 13:56 |
| mup | Bug #568981: Enable uploading a public gpg key using the API <Launchpad Registry:New> <https://launchpad.net/bugs/568981> | 13:56 |
| mup | Bug #568982: Enable uploading a public ssh key using the API <launchpadlib :New> <https://launchpad.net/bugs/568982> | 13:56 |
| sinzui | didrocks, why is sshkeys targeted to launchpadlib? ssh key code is in launchpad-registry | 13:58 |
| didrocks | sinzui: my bad, retargetting | 13:58 |
| didrocks | I took the other bug as a reference and mis-middle click :) | 13:59 |
| didrocks | fixed | 13:59 |
| * jml lunches | 14:14 | |
| maxb | Staging broken? | 14:19 |
| mars | maxb, looks down to me | 14:21 |
| maxb | We could really use a status page for staging & edge autoupdate | 14:22 |
| mars | maxb, it is on my personal todo list | 14:22 |
| mars | the question is finding time to personally do it :) | 14:23 |
| mars | I don't have time outside of work for hacking | 14:23 |
| === ChanServ changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 2 of 10.04 | PQM is open | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in irc://irc.freenode.net/#launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | staging is down! | ||
| mhall119 | is there currently any work being done to add a wiki to Launchpad? | 14:31 |
| mhall119 | it looks like there used to be blueprints for it | 14:31 |
| bigjools | jml: ^^ :) | 14:33 |
| jml | mhall119, there's no funded work going on | 14:33 |
| jml | mhall119, some of the Launchpad developers are working on something like it in their spare time | 14:33 |
| mhall119 | jml: do you know which ones? | 14:33 |
| jml | mhall119, thumper, mostly | 14:33 |
| mhall119 | thumper: are you still working on a Launchpad Wiki component? | 14:34 |
| jml | mhall119, it's 1:30am where thumper is | 14:34 |
| mhall119 | oh, nevermind then | 14:34 |
| mhall119 | maybe I'll catch him tonight | 14:35 |
| mhall119 | I'm hoping it'll be like bitbucket's wiki, only with bzr instead of hg | 14:35 |
| jml | mhall119, I'm not sure that thumper is being inspired by bitbucket, but I'm pretty sure it's a bzr-backed wiki | 14:35 |
| jml | mhall119, we've been talking about this for a very long time | 14:36 |
| mhall119 | cool | 14:36 |
| mhall119 | I like being able to work on a wiki offline, or mass-edit with CLI tools, then merge it back in | 14:37 |
| persia | lp:wikkid is the link posted earlier, if someone wants to look at WIP | 14:37 |
| mhall119 | often times I've wished I could do that with wiki.ubuntu.com | 14:37 |
| persia | (posted in #launchpad about 12 hours back) | 14:37 |
| persia | mhall119: editmoin | 14:37 |
| mhall119 | persia: thanks, but I don't think that's quite the same | 14:38 |
| persia | heh, true. | 14:39 |
| mhall119 | I'm branching wikkid right now though | 14:39 |
| mhall119 | thanks for that refference | 14:39 |
| persia | #launchpad is an informative channel : I recommend it's backscroll. | 14:42 |
| henninge | allenap, adeuring, gmb: Can either of you resolve the two merge conflicts in lib/lp/bugs/scripts/checkwatches/tests/test_core.py, please? | 15:18 |
| henninge | lib/lp/bugs/scripts/checkwatches/tests/test_core.py | 15:18 |
| henninge | http://paste.ubuntu.com/421058/ | 15:18 |
| henninge | There it is ^ | 15:18 |
| allenap | henninge: I'll look. | 15:18 |
| allenap | henninge: Is this when merging from devel into db-devel? | 15:19 |
| henninge | allenap: into production-stable, yes. | 15:19 |
| allenap | henninge: production-devel into production-stable? | 15:20 |
| henninge | allenap: sorry ;-) | 15:20 |
| allenap | henninge: There's stuff in there that shouldn't be anywhere near production yet. | 15:21 |
| henninge | allenap: I have a branch based on production-stable but now I want to merge it into devel, so I am merging devel into it. | 15:21 |
| henninge | was a c-p candidate originally. | 15:21 |
| allenap | henninge: Why not start a fresh devel branch and merge the production-stable branch into it? | 15:22 |
| allenap | henninge: Oh I guess it's much the same. | 15:22 |
| henninge | allenap: that was my next option but I was down to two conflicting files, so I thought might as well resolve those. | 15:22 |
| henninge | allenap: the result will be merged in to devel (just to be clear). | 15:22 |
| allenap | henninge: Can you point me to your production-stable branch? I can help you fix the conflicts, but I want to understand *why* it's conflicting. IIUC, it shouldn't. | 15:24 |
| henninge | sure | 15:24 |
| bac | hi thekorn, do you know how to call a destructor on a lplib object? bug 534363 implies there is a trick. | 15:24 |
| mup | Bug #534363: no easy way to call destructor <usability> <launchpadlib :Triaged> <https://launchpad.net/bugs/534363> | 15:24 |
| henninge | allenap: https://code.edge.launchpad.net/~henninge/launchpad/bug-565294-nplurals | 15:25 |
| allenap | henninge: Thanks. | 15:25 |
| sinzui | allenap, do you have time to read and reply to my proposal to fix the needs-packaging timeouts? | 15:27 |
| allenap | sinzui: I read it a couple of times but I didn't really take it in very well. I'll look again today, and get back to you. Will that be okay? | 15:31 |
| sinzui | allenap, yes. I picked you because I am extending the not-so-temporary table you added. You may have thoughts about how to make it untemporary and maybe a cron process is wrong | 15:32 |
| thekorn | bac, sorry, I don't know anything about launchpadlib and DELETE, and I also don't think there are any DELETE methods eposed through the API yet | 15:32 |
| allenap | sinzui: IIRC, bigjools had some ideas about that at the time. | 15:33 |
| thekorn | I think all destructors are POST methods until now | 15:33 |
| allenap | henninge: If you take a fresh branch of devel, the following will merge your changes without conflict: bzr merge -r 9192.. lp:~henninge/launchpad/bug-565294-nplurals | 15:33 |
| sinzui | bac: maybe we should unexport delete milestone and declare victory | 15:33 |
| bac | thekorn: thanks. there are some, and i'm trying to fix one. the ones that already exist don't appear to work, though. | 15:34 |
| bac | sinzui: can i haz my week back? | 15:34 |
| allenap | henninge: You probably know this now, but CPs are less hassle when landed in devel first. I have made that mistake before. Or was there a reason? | 15:35 |
| henninge | allenap: no, no other reason. | 15:35 |
| henninge | allenap: so you mean, land in devel, then merge the revisions into a production branch and hand that of for cp? | 15:36 |
| henninge | allenap: In this case I was trying to avoid using a new devel branch so that all the mp and qa automatic keeps working. | 15:37 |
| sinzui | bac: all work is about scope management. Always state how much your time is worth when you start, fix the core problem first, them incorporate tech-debt for good karma as time allows | 15:37 |
| henninge | but oh well, can't have everything ... | 15:37 |
| * sinzui will not work on any trivial bug for more than 1 hour | 15:38 | |
| allenap | henninge: Yes. I suspect the policy is there to make sure the code is landed so that we don't regress next release. | 15:38 |
| allenap | henninge: Eurgh :) | 15:38 |
| * henninge googles that ... ;) | 15:39 | |
| allenap | henninge: Fwiw, https://wiki.canonical.com/Launchpad/PolicyandProcess/EmergencyChange says to land in devel first too. | 15:40 |
| henninge | wow, should have read that page first ... | 15:42 |
| henninge | allenap: thanks | 15:43 |
| henninge | allenap: so can you resolve the file or should I go the new-devel-branch road? | 15:43 |
| allenap | henninge: Please go the new-devel road. It merges cleanly which has got to be a good thing, especially as gmb is doing some major refactoring in the checkwatches package. | 15:46 |
| henninge | allenap: ok, np. Have a nice weekend! ;) | 15:47 |
| allenap | henninge: I think it makes sense to have a separate merge proposal anyway (and you can link back to the first one), and if the auto-qa-tagging thing doesn't understand the situation then it's a bug in the auto-qa-tagging machinery. | 15:47 |
| allenap | henninge: You too :) | 15:47 |
| henninge | ah, right | 15:47 |
| cody-somerville | I'm a bit confused by setBugSupervisor. Why does it take two arguments? | 16:17 |
| jpds | cody-somerville: Permission checking in userCanAlterSubscription() ? | 16:28 |
| cody-somerville | jpds, I think you're guessing | 16:29 |
| james_w | cody-somerville: the second is the person doing the setting | 16:42 |
| james_w | call_with(user=REQUEST_USER) over the API | 16:42 |
| === matsubara is now known as matsubara-lunch | ||
| === almaisan-away is now known as al-maisan | ||
| === beuno is now known as beuno-lunch | ||
| === matsubara-lunch is now known as matsubara | ||
| === beuno-lunch is now known as beuno | ||
| mrevell | night | 18:33 |
| sinzui | EdwinGrubbs, didn't we fix the shadowing issue described in bug 567583 6 months ago? | 18:59 |
| mup | Bug #567583: API collections shadow the default traversal <Launchpad Registry:New> <https://launchpad.net/bugs/567583> | 18:59 |
| === gary_poster is now known as gary-lunch | ||
| jml | james_w, how do I use lazr.restfulclient.tx without installing it? | 19:24 |
| jml | python really isn't built for namespace packages :\ | 19:26 |
| cody-somerville | sinzui, for LP #444266, where would I write the tests for that? There doesn't appear to be any good existing doctest to add to in lp/bugs/stories/webservice/ | 19:37 |
| mup | Bug #444266: Expose project bug supervisor and security contact via API <api> <oem-services> <Launchpad Bugs:In Progress by cody-somerville> <https://launchpad.net/bugs/444266> | 19:37 |
| * sinzui thinks | 19:38 | |
| sinzui | cody-somerville, I think you want to create a new test for the api. hasbugsupervisor maybe? | 19:39 |
| sinzui | in lp/bugs/stories/webservice/ | 19:39 |
| cody-somerville | is the security contact a part of registry or bugs? | 19:41 |
| sinzui | bugs | 19:41 |
| sinzui | That has a separate interface | 19:41 |
| sinzui | maybe we can add a bugtarget.txt doctest to that directory to cover both | 19:41 |
| EdwinGrubbs | sinzui: no, we didn't solve the underlying cause. I just changed the name of the "releases" series that was colliding with IProduct.series. I then assigned bug 432766 to leonard. | 19:42 |
| mup | Bug #432766: instance name can shadow object attributes <Launchpad Foundations:Triaged by leonardr> <lazr.restful:Triaged> <https://launchpad.net/bugs/432766> | 19:42 |
| sinzui | cody-somerville, I expect those fields to be visible to anon api | 19:42 |
| sinzui | EdwinGrubbs, thanks. | 19:42 |
| EdwinGrubbs | sinzui: I marked the bug as a duplicate | 19:42 |
| sinzui | even more gratitude | 19:43 |
| cody-somerville | sinzui, The only interfaces that have a security_contact field exist in registry. | 19:43 |
| sinzui | cody-somerville, yes. that interface is a problem. it is design has proven to be an issue when we try to make a single page to set bug configuration | 19:44 |
| jml | how do I get the JSON dict from a launchpadlib object? | 19:45 |
| sinzui | cody-somerville every bugtarget is also a registry object, but the security contact is only used by bugs. | 19:45 |
| sinzui | cody-somerville, you can only set that field is bug tracking is enabled. I think that is stupid. | 19:46 |
| jml | lpobj._wadl_resource.representation does the trick | 19:47 |
| jml | don't worry, I don't intend to let anyone else use this code | 19:47 |
| cody-somerville | sinzui, In fact, the only interface I see that has a security_contact field is series and that just says it references the parent security contact. | 19:49 |
| sinzui | cody-somerville, I am telling you the truth. bugtarget is the answer. There is a long history of application wrongly placing attributes on common objects. This makes refactoring difficult, the modules are long, and confuses new hackers who do not know who really owns the feature. | 19:50 |
| sinzui | cody-somerville, think of it this way, if an application does not use launchpad bugs, it cannot have a security contact or a bug supervisor. if we got rid of that application the fields would not be used. Thus those fields are the domain of Launchpad Bugs. | 19:52 |
| cody-somerville | sinzui, I understand that | 19:52 |
| cody-somerville | sinzui, I'm asking you though, where is the actual interface that these models are implementing that has the security_contact field so I can decorate it? | 19:53 |
| sinzui | I do not recall since I do not work with it. I bet based on its age that is canonical.launchpad.interfaces.launchpad.IHasSecurityContact | 19:54 |
| === gary-lunch is now known as gary_poster | ||
| cody-somerville | sinzui, good call | 20:05 |
| sinzui | Maybe 3 years it too long to work on a project when you can take a blind stab at an answer and nail it | 20:06 |
| cody-somerville | sinzui, Now, what prevents someone without the correct permissions from modifying bug supervisor/security contact? Just the view? | 20:07 |
| sinzui | I think permission on the implementer state who can change the field. | 20:08 |
| * sinzui looks | 20:08 | |
| sinzui | security_contact: launchpad.Edit | 20:08 |
| sinzui | setBugSupervisor: launchpad.Edit | 20:09 |
| sinzui | cody-somerville, The permissions are on the object and restful will enforce that | 20:09 |
| cody-somerville | awesome | 20:10 |
| cody-somerville | I remember reading something about permissions and views and wanting to make it apply automatically to restful stuff? What was that all about? | 20:10 |
| sinzui | zope.Public is the an implicit permission in some cases on objects/views. Restful ignored that, and the consequence is that some objects/attributes cannot be viewed via anonymous access. We need to add permission to security.py to explicitly allow those objects to be visible to anonymous users. IDistributionMirror is an example | 20:13 |
| cody-somerville | sinzui, How do I export bug_supervisor as readonly? I thought I could pass readonly=True to exported but that doesn't appear to be true. | 20:16 |
| sinzui | It is read only I think | 20:17 |
| cody-somerville | you think it already is? | 20:18 |
| cody-somerville | or the argument is called just 'read'? | 20:19 |
| sinzui | cody-somerville, there is no set_attributes declaration for bug_supervisor. No callsite can change the value without getting stripping the security wrapper | 20:19 |
| sinzui | cody-somerville, have you verified in a test that someone can change that attribute? | 20:20 |
| sinzui | A launchpad view running for an admin would get a forbidden error if it tried to change that field | 20:20 |
| cody-somerville | I guess I'll generate the apidocs and see what it says | 20:21 |
| cody-somerville | sinzui, the bug supervisor stuff doesn't show up in apidocs. security_contact does though. I think its because IProduct does not inherit IHasBugSupervisor whereas it does IHasSecurityContact. | 20:29 |
| sinzui | cody-somerville, yes. I suspected one of these would be a problem. I assumed that is why it was not exported in the past | 20:30 |
| sinzui | I think IHasSecurityContact needs to be exported too. It may need a url defined since restful cannot access anything without a URL. | 20:31 |
| cody-somerville | sinzui, security_contact shows up fine. I just exported security_contact field in IHasSecurityContact like normal. | 20:32 |
| sinzui | I think this is like the issue we had with IDistributionMirror. We added a checker to security.py and a browser:url to browser/configure.py as well as exporting the base interface | 20:32 |
| sinzui | does the interface also have this: export_as_webservice_entry() | 20:33 |
| cody-somerville | sinzui, no | 20:34 |
| sinzui | Add that, I think you do need to add a security checker and a url. | 20:34 |
| cody-somerville | sinzui, For IHasSecurityContact? why would we want this to be a webservice entity? | 20:35 |
| sinzui | cody-somerville, I am off to rescue my children from the state institution. you can cargo cult IDistributionMirror examples from security.py and browser/configure.zcml to get the two missing parts | 20:35 |
| cody-somerville | sinzui, IProject inherits IHasSecurityContact so why would IHasSecurityContact need to be its own webservice entity? | 20:36 |
| thumper | gary_poster: I'm wanting to be able to turn a canonical_url into a list of traversed objects (attached to a request even better) | 20:36 |
| thumper | gary_poster: but I couldn't find the right hooks in the publisher code | 20:36 |
| thumper | gary_poster: instead of getting too frustrated, I thought I'd just ask you | 20:36 |
| thumper | gary_poster: as I have a feeling you'll know where to look | 20:36 |
| thumper | gary_poster: it is for testing breadcrumbs more easily | 20:37 |
| thumper | gary_poster: the current way requries passing in the traversed objects list | 20:37 |
| gary_poster | thumper :-) I'll try at least. | 20:37 |
| thumper | gary_poster: but I think that should really be unnecessary | 20:37 |
| thumper | gary_poster: we should be able to say "create me the breadcrumbs for this object" | 20:37 |
| thumper | gary_poster: and have the test hook into the publisher then create the view | 20:38 |
| thumper | I have to go get the girls up now, but I'll check back later | 20:38 |
| gary_poster | thumper, in classic Zope 3 you'd walk up the __parent__ list. OK, cool, I'll look at code for a sec, and then confer with flacoste if I don't see anything | 20:39 |
| gary_poster | s/list/pointers | 20:39 |
| gary_poster | OK I've read it three times and I think I understand what you want. looking... | 20:41 |
| cody-somerville | why does IHasBugSupervisor subclass IStructuralSubscriptionTarget? | 20:52 |
| james_w | jml: I had to use a mess of virtuaenv and symlinks | 20:57 |
| === EdwinGrubbs is now known as Edwin-lunch | ||
| gary_poster | thumper: I reacquainted myself with some of the pertinent code, and though I'm still not confident I understand what you mean, I'm not optimistic. Maybe point me to a concrete example of what's going on now, with an example of what you want, and I'll give it another whirl? | 21:02 |
| gary_poster | james_w, fwiw, as they exist now, namespace packages won't work if the namespace package actually has code in it. If you actually wanted to release lazr.restfulclient.tx, it would need to be lazr.restfulclient.plugins.tx, or something, where "plugins" has no code. I don't remember if the PEP for namespace packages lifts that restriction or not, but that is the case for now, anyway. | 21:03 |
| gary_poster | lazr.restfulclient-tx? | 21:04 |
| gary_poster | dunno what it is | 21:04 |
| james_w | Gary_poster: thanks for the tip. I'll probably end up changing the name. | 21:08 |
| gary_poster | cool | 21:08 |
| james_w | It's a fork of lazr.restfulclient based in twisted with some experiments thrown in. | 21:10 |
| gary_poster | oh! experiments good, fork, boo :-/ | 21:10 |
| gary_poster | is there something we could do to not encourage a fork? | 21:11 |
| thumper | gary_poster: I'm wanting to create the +hierarchy view for an object, however the request for create_initialized_view has no traversed objects, and the hierarchy view uses those | 21:14 |
| thumper | gary_poster: I want to check the items of that view to check the breadcrumbs for any object | 21:14 |
| thumper | gary_poster: so... given any object, get the canonical_url for it, work out the traversed objects, and create a request with that to pass into create_initialized_view | 21:15 |
| thumper | gary_poster: for simple breadcrumb testing | 21:15 |
| thumper | gary_poster: I'm sure a method to get the traversed objects for any given other object would be a very helpful testing function | 21:15 |
| gary_poster | ok, thumper. Maybe. Looking. | 21:15 |
| gary_poster | so, thumper, a test request is not just ok but good, right? | 21:16 |
| thumper | gary_poster: yes | 21:16 |
| gary_poster | k | 21:16 |
| === Edwin-lunch is now known as EdwinGrubbs | ||
| james_w | gary_poster: we can refactor lazr.restfulclient so that we can share code, but it has a lot of sync assumptions and the API makes no sense for twisted. | 21:27 |
| gary_poster | thumper, the best I can come up with is to suggest that you refactor the code in canonical_url. It does most everything you want, I think, but discards the parts you care about. | 21:28 |
| thumper | gary_poster: hmm... | 21:29 |
| thumper | gary_poster: ok, I'll take a look monday | 21:29 |
| thumper | gary_poster: thansk | 21:29 |
| gary_poster | cool, thumper | 21:29 |
| gary_poster | np | 21:29 |
| thumper | gary_poster: although I was hoping that we could hook into the publishTraverse somewhere | 21:29 |
| thumper | gary_poster: I don't think we'd get exactly the same answer | 21:30 |
| gary_poster | thumper: understood. there's a reason that canonical_url is so messy though. :-/ | 21:30 |
| thumper | not all the time anyway | 21:30 |
| gary_poster | james_w: I'm a big +1 on Twisted support, very understanding of the differences necessary for async, and unhappy if there is a lot of code duplication between the original and the fork, as I think there would be. If you (and jml?) had suggestions on a refactoring to make code sharing easy, I'd be eager to come to an agreement and incorporate them, rather than see a fork develop. | 21:34 |
| james_w | art_poster: I'm not happy with a fork either, and it's huge duplication right now. its also just a toy right now, if it has legs then I'll push for sharing what we can. | 21:37 |
| james_w | Sorry, crappy phone keyboard :) | 21:37 |
| gary_poster | LOL | 21:38 |
| gary_poster | james_w: OK, great sounds good | 21:38 |
| cody-somerville | How do I fix 'zope.configuration.config.ConfigurationConflictError: Conflicting configuration actions'? | 21:40 |
| mars | cody-somerville, sinzui may know. He wrote our configuration libraries. | 21:58 |
| sinzui | mars, no, cody-somerville is talking about ZCML | 21:58 |
| cody-somerville | sinzui, you're back :) | 21:59 |
| sinzui | cody-somerville, I have experienced that. You have added a duplicate permission rule for an object/attribute. ZCML allows only one rule. | 21:59 |
| sinzui | cody-somerville, Search for the Interface or attribute you added to locate the current rule and update that rule instead | 21:59 |
| cody-somerville | I didn't touch ZCML | 22:00 |
| sinzui | oh? | 22:00 |
| sinzui | yuck | 22:00 |
| * sinzui thinks | 22:00 | |
| sinzui | cody-somerville, did you add a browser:url? | 22:00 |
| cody-somerville | Nope | 22:00 |
| cody-somerville | I started getting that error when I made IProductPublic inherit IHasBugSupervisor. | 22:00 |
| cody-somerville | I noticed a bunch of methods and what not for IStructuralSubscriptionTarget and then noticed IHasBugSupervisor inherits IStructuralSubscriptionTarget and so does IProduct | 22:01 |
| cody-somerville | so I made IHasBugSupervisor just inherit from Interface and it reduced the complaining to just the bug_supervisor and setBugSupervisor attribute and method respectively. | 22:01 |
| wgrant | cody-somerville: So, basically, Zope security ZCML sucks. | 22:07 |
| wgrant | Instead make IProduct inherit IHasBugSupervisor, not IProductPublic. | 22:07 |
| wgrant | Unless you want to split IHasBugSupervisor into two. | 22:07 |
| sinzui | I agree with wgrant's first assertion and first suggestion | 22:08 |
| cody-somerville | okay | 22:08 |
| wgrant | (if you look in lib/lp/registry/configure.zcml, you'll see that those two attributes already have manual declarations for IProduct and IDistribution) | 22:08 |
| cody-somerville | Is it correct to make IHasBugSupervisor subclass Interface instead of IStructuralSubscriptionTarget? I can't understand why it would. | 22:09 |
| cody-somerville | (why it would subclass IStructuralSubscriptionTarget that is) | 22:09 |
| sinzui | cody-somerville, I think you may want to remove the ZCML rules on the pillar for bug_supervisors. define the rules just on IHasBugSupervisor | 22:09 |
| === matsubara is now known as matsubara-afk | ||
| wgrant | sinzui: Aren't permissions applied to classes, not interfaces? | 22:10 |
| wgrant | cody-somerville: Some of the bug supervisor stuff might touch structural subscriptions. | 22:10 |
| wgrant | Grep around, I guess. | 22:10 |
| sinzui | cody-somerville, removing IStructuralSubscriptionTarget as a base will break subscription behaviour I think | 22:10 |
| cody-somerville | Why? | 22:11 |
| cody-somerville | IProduct inherits IStructuralSubscriptionTarget | 22:12 |
| wgrant | It won't break it. | 22:12 |
| cody-somerville | and IHasBugSupervisor should have nothing to do with IStructuralSubscriptionTarget - the fact that the bug supervisor creates a bug subscription is an implementation detail, right? | 22:13 |
| wgrant | But it might be wrong. | 22:13 |
| sinzui | cody-somerville, did you check every object that inherits IHasBugSupervisor? | 22:13 |
| cody-somerville | sinzui, Not yet. | 22:14 |
| === al-maisan is now known as almaisan-away | ||
| cody-somerville | Why does setBugSupervisor in IHasBugSupervisor have self as an argument? I thought interfaces didn't need 'self'? | 22:18 |
| sinzui | cody-somerville: I think lint will tell you you are right | 22:19 |
| wgrant | s/didn't need/cannot have/ | 22:20 |
| wgrant | A verifyObject test will probably start failing if you don't fix that. | 22:20 |
| sinzui | cody-somerville, I think you can can make every product and distribution inherit from both IStructuralSubscriptionTarget and IHasBugSupervisor, then make IHasBugSupervisor descend from Interface | 22:20 |
| cody-somerville | woot. got make to work now. | 22:21 |
| cody-somerville | I should probably make bug_supervisor read only but will that break anything or does it only affect the the webservice API? | 22:23 |
| wgrant | It may affect forms too. | 22:24 |
| wgrant | You should also not export setBugSupervisor directly -- instead export it as the mutator for bug_supervisor. | 22:24 |
| sinzui | cody-somerville, If you copied the original permission, the attribute is read-only | 22:25 |
| wgrant | gary_poster: Um, so you're going to be sending privileged cookies over HTTP? | 22:29 |
| wgrant | Even if they have a short lifetime, that is...... um..... | 22:29 |
| gary_poster | wgrant, yup | 22:29 |
| wgrant | ............ | 22:30 |
| wgrant | Does this come under 'who could possibly think that was a good idea?', or am I missing something? | 22:31 |
| gary_poster | wgrant, the question is a matter of balance, as usual. Right now, the plan is that identity uploads and private teams, projects etc. would be over HTTPS (with their own separate cookies). The rest would be on HTTP. | 22:35 |
| gary_poster | HTTPS costs around 30-40% of a typical download cost for our pages. We feel that there are large swaths of actions working on normal public content that don't need HTTPS. github is a competitor (sorta) I'm familiar with; they feel similarly, apparently. | 22:35 |
| gary_poster | It's been discussed internally, but if you wanted a debate it would be reasonable and healthy. If I don't convince you quickly, we should take it to the list. | 22:36 |
| wgrant | gary_poster: You know there are Launchpad POSTs on public objects that can publish code to many millions of users? | 22:37 |
| wgrant | Making Launchpad less secure should not be a priority. | 22:37 |
| gary_poster | Making it faster is. | 22:37 |
| wgrant | It guards things that are vastly more important than anything GitHub has direct access to. | 22:37 |
| gary_poster | That's the single biggest change we can make to do that. | 22:37 |
| wgrant | Serve public reads over HTTP, sure. | 22:37 |
| wgrant | Include an unprivileged cookie in these requests so you can render the pages as if they were authenticated. | 22:38 |
| wgrant | But writes over HTTP? Ew. | 22:38 |
| gary_poster | wgrant: That's the plan, and it is certainly not without precedent. We have discussed adding an additional level of protection for projects, in addition to "private": "protected". This would be public, but forced over HTTPS. This would be opt-in. | 22:43 |
| gary_poster | Your point of sending bunches of email is a good one though | 22:43 |
| wgrant | gary_poster: So you are seriously going to allow insecure write requests? | 22:43 |
| flacoste | what is the "bunches of email" point? | 22:43 |
| wgrant | I made no bunches of email point. | 22:43 |
| wgrant | I made a "bunches of malware" point, though. | 22:44 |
| flacoste | wgrant: the first goal is to allow HTTP for read-only public stuff | 22:45 |
| gary_poster | I misread the comment. If you are discussing PPAs, granted. | 22:45 |
| elmo | flacoste: no one's objecting to that | 22:45 |
| elmo | flacoste: it's the writes that the problem | 22:45 |
| flacoste | wgrant: we'll consider write over HTTP in a second iteration after a proper risk-analysis | 22:45 |
| wgrant | gary_poster: Launchpad has one very large project: Ubuntu. | 22:46 |
| wgrant | Not just PPAs. Much, much worse. | 22:46 |
| wgrant | flacoste: OK, good to know. | 22:46 |
| gary_poster | wgrant, yes. | 22:46 |
| flacoste | wgrant: there are multiple place where write over http wouldn't be a problem from a RA perspective: filing and commenting on bugs for example | 22:46 |
| wgrant | flacoste: That is a security issue. | 22:46 |
| wgrant | Projects use bugs for admin requests. | 22:47 |
| flacoste | everything is security issue | 22:47 |
| wgrant | eg. Ubuntu uses them for sync requests. | 22:47 |
| flacoste | that's why you have risk analysis | 22:47 |
| wgrant | OK, an *actual security problem*, then. | 22:47 |
| flacoste | that's interesting, so you can trigger a Debian sync from an email to Launchpad? | 22:48 |
| flacoste | GPG-signed of course | 22:48 |
| elmo | I suspect some of the exposed archive stuff would also be an interesting avenue for serious abuse | 22:48 |
| wgrant | Not automatically, but yes. | 22:48 |
| wgrant | elmo: Oh yes. | 22:48 |
| wgrant | A quick syncSource here and there... | 22:48 |
| flacoste | anyway, we aren't opening those gates yet | 22:48 |
| flacoste | but thanks for verifying that a RA was on our plan before we did :-) | 22:49 |
| wgrant | U1 manages to do AJAX over HTTPS with <500ms from here. | 22:53 |
| wgrant | There's no reason for your writes to take much longer than that. | 22:54 |
| wgrant | So I really don't see the benefit in throwing security out the window. | 22:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!