[01:29] StevenK: auditor has no buildout now ? [02:33] I just discovered an old branch I was working on , on this laptop. [02:33] I wonder if I can finish it. Hrm. [02:35] lifeless: auditor itself is not buildout enabled, no. [02:37] lifeless: Actually, what do you mean 'now'? auditor never had buildout. [03:30] Project devel build #1099: STILL FAILING in 1 min 23 sec: https://lpci.wedontsleep.org/job/devel/1099/ [03:34] Yippie, build fixed! [03:34] Project devel build #1100: FIXED in 3 min 26 sec: https://lpci.wedontsleep.org/job/devel/1100/ [03:35] Jenkins, you lying scoundrel [03:37] never trust it :P [03:42] rick_h_: Hmph. [03:44] Right, build 1101 is off and looking good, so time for some DEHR === bigjools-afk is now known as bigjools_ [04:50] StevenK: I assumed it would [04:50] StevenK: as its what we use for deploys [04:50] lifeless: No, that's production-auditor [05:07] wgrant: you were doing something about 263 / 0 POFile:+translate [05:07] were you not ? [05:07] Project devel build #1101: FAILURE in 1 hr 29 min: https://lpci.wedontsleep.org/job/devel/1101/ [05:09] lifeless: It's a terrible page in general, it's not just the query that I was looking at. But I eventually established that we probably can't optimise that query significantly without changing to something sensible like FTI, rather than substring matching. [05:10] (but that has obvious problems, given all the languages) [05:13] bllllar, pypi login is very odd [05:13] it had basic creds [05:13] so knew who I was [05:13] but wasn't showing my logged in [05:13] s/my/me/ [05:13] click on 'login' and it changed to logged in. [05:14] ahhaha [05:14] http://pypi.python.org/pypi/Ojota/0.4.2 [05:14] ' License: LICENSE.txt ' [05:15] I am filled with confidence [05:20] linear operation dispatch [05:20] sigh, they need mentoring. [05:29] bah, codus interruptus. I will try to get back to this later. [05:55] Neat, concurrency 4 is 30 minutes quicker. [05:56] lifeless: https://lpci.wedontsleep.org/job/devel/lastBuild/ has your build artifacts [06:48] wgrant: https://code.launchpad.net/~stefanor/launchpad/packageset-destructor/+merge/127167 dropped the export_operation_as. Care to land it? [06:49] tumbleweed: Sure [06:49] Thanks [06:49] btw, that export_operation_as was there because I saw it in some other places. Should they be cleaned up? [06:50] Hm, which other places? export_destructor_operation has only been around for a couple of years, so some may have been incorrectly ported. [06:50] ack-grep says lib/lp/blueprints/interfaces/specificationbranch.py lib/lp/registry/interfaces/milestone.py [06:50] oh, and lib/lp/registry/interfaces/productrelease.py [06:51] Hmm [06:51] Those are possibly relevant to old versions of the API [06:55] tumbleweed: Can you set a commit message? [06:56] wgrant: done [06:59] tumbleweed: Thanks. That's landed. [07:02] thank you :) === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [07:43] good mmorning [07:55] ok [07:55] so why does django test discovery not look in submodules [07:55] adeuring: ello ello [08:03] lifeless: Can haz another peek at jenkins? [08:23] tumbleweed: The destructor change is through buildbot, and should be in the next production deployment. [08:28] yup, got an e-mail, thanks [08:33] StevenK: remind me tomorrow, its late and i've been kicking django basics around === mpt_ is now known as mpt === gary_poster|away is now known as gary_poster === benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: benji | Firefighting: - | Critical bugs: ~300 [13:31] adeuring, abentley -- hey, having trouble connecting to the hangout. still trying to get in... [13:31] deryck: ack. [14:42] My house is full of plague. I an not getting our of jim-jams today [14:44] * czajkowski passes a hot whiskey to sinzui [14:44] I please no [14:44] I don't think it will stay down [14:45] I am trying not to ingest [14:45] sinzui: any reason why a person cant sign the CoC with a subkey not their primary key ? [14:45] czajkowski, very good reasons [14:46] mind telling them to the chat in -lp please :) [14:46] *chap [14:46] czajkowski, Last week we downgraded gpg on several of our servers because an unneeded security fix for dpkg was applied. [14:46] sinzui: https://bugs.launchpad.net/launchpad/+bug/1053568/comments/4 <-- that [14:46] <_mup_> Bug #1053568: PPA uploads signed with subkeys silently fail

< https://launchpad.net/bugs/1053568 > [14:46] czajkowski, We downgraded the machines we knew of. [14:47] czajkowski, right [14:47] ah so I was right [14:47] if the problem returned, we need to ask if webops applied the security fix again...out machines were not affected by the issue [14:48] security fix to gnupg, wasn't it, not dpkg? [14:48] https://launchpad.net/ubuntu/+source/gnupg/1.4.10-2ubuntu1.1 [14:50] cjwatson, yes [15:27] abentley, adeuring -- do you guys expect any db patches this week, beyond my patch for Product.information_type? [15:28] deryck: can't think of any right now [15:28] adeuring, ack, thanks [15:29] deryck, adeuring: Are we going to need to extend AccessArtifact to support Products? [15:29] abentley, deryck: can't we use simply policy grants? [15:30] yeah, I was under the impression from adeuring that this was a little simpler for products and didn't require AccessArtifact. [15:30] adeuring: Yes, I think that makes sense. [15:31] after all, policy grangts already give access to branches, bugs, specs, so its "natural" to extend this to give access to the pillar/product itself [15:45] adeuring, but no new db patches needed, though, right? [15:45] deryck: right, i think we don't need any. [15:46] awesome. [15:46] trying to coordinate since webops are sprinting. === deryck is now known as deryck[lunch] [17:20] deryck[lunch]: ping when you get back === deryck[lunch] is now known as deryck [18:05] hi cjohnston. have a call now, but I can ping after that. [18:33] ok deryck [19:00] cjohnston, hey. Free now. What's up? [19:01] deryck: I want to make sure I understand.. So as Summit is not authenticated, it will not see any private BPs that are proposed to the UDS sprint? [19:02] cjohnston, correct. [19:03] Ok.. so your comments confuse me a little.. If Summit doesn't have the ability to see it, is there a reason for the ability for a BP to be proposed to a sprint to exist? [19:04] otherwise it still seems like a confusing UI as I propose my blueprint to a UDS sprint, I assume that more than likely the people who approve blueprints for the sprint can't see the blueprint to approve it for the sprint, even if they can, Summit can't see the blueprint to create the (private) meeting [19:06] So either the functionality needs to be extended to work correctly, or removed from private BPs, IMO [19:06] cjohnston, what do you call "correctly?" What needs to happen to be correct? [19:07] Where if a blueprint is proposed to a sprint, a 'sprint manager' can approve the blueprint for the sprint, and Summit sees the approved blueprint and creates a (private) meeting for the blueprint [19:09] Otherwise it doesn't perform as expected [19:09] by the user, based on how other blueprints perform [19:10] The point about the sprint manager not being able to see it is a good point. I'm not sure its a bug or not yet. I need to think through that case. [19:10] but even still, if the sprint manager could see it, Summit couldnt [19:10] As for summit, that's different. it's an add-on bit to launchpad. so I don't think we want to automatically trust anonymous bots. [19:11] ah, ok, I guess I don't understand how summit gets access. [19:11] I thought it was anonymous API script, based on what you said earlier. [19:12] 1 sec... trying to find the link [19:13] https://launchpad.net/sprints/uds-r/+temp-meeting-export [19:14] cjohnston, ok, so I think it's good to chat and work out any kinks here, but I don't think this anything we're going to change on our end before UDS…. [19:14] cjohnston, the people who will be bitten by this are a small group.... [19:15] well.. the new stuff is only in beta currently correct? [19:15] cjohnston, only people who are both lp beta testers and have commercial subscriptions for lp….. [19:15] oddly enough I actually fall into it.. hehe [19:15] fair point :) [19:16] but yes.. it is a small group, and for this UDS I think we are ok.. but I'd like to have it correct before we start the planning for the next UDS when all of this is live [19:16] cjohnston, so people who do fall in that, need to be careful about using private blueprints linked to UDS. [19:16] so somehow we would have to get that info out to them [19:17] as to the larger point, everything private in lp works the way blueprints do now. If it's proprietary, then no one gets access accept those people explicitly given access. I don't think we should change this. [19:17] maybe that means that proprietary blueprints shouldn't be able to be linked to a sprint. [19:17] I'm not sure agree, but its a fair point to argue. [19:17] That's my thought.. or that if they are, then everything else needs to be changed to accomidate the fact that they can link it [19:18] otherwise it gets stuck in some foriegn world [19:18] well, no, it's private. As they the word "private" implies. :) [19:19] correct.. its private.. but they propose it to a sprint, but it never makes it onto the schedule [19:19] thats where the problem as I see it lies [19:19] are sprints proposed, or just purely linked to the sprint object? [19:20] I assumed it was a straight link, but if it is an proposed relationship that can never be approved or rejected, then yes, that's a clear bug. [19:20] I don't understand the question? A sprint itself is created, and a BP is proposed against a sprint [19:22] ok, so I just checked. You get the link on your blueprint, but it's not listed without approval. [19:23] so you have kind of an unofficial link to a sprint [19:24] so how would it get approved [19:24] it wouldn't. but why is that bad if it's a private object? [19:25] then it shouldn't be able to be proposed.. what is the point of proposing a blueprint to a sprint if you cant get the blueprint approved for the sprint? [19:26] I don't know. It's hypothetical, sure. I don't know that anyone wants this relationship. But I imagine someone *could* be working on something private while at UDS, and like the link to the sprint to see to establish the relationship, i.e. as a point of navigation to the sprint for other stuff. [19:26] I don't know this, I'm just speculating. [19:26] But without talking to people who might use this, we can never know. [19:28] I guess to me, I would rather that if the feature not work the same as it works for everything else, it shouldn't exist. I am not opposed to making it possible to propose a private bp, get it approved (somehow?), we want to make summit authenticate anyway, so then we could create a private meeting (a feature that already exists in Summit) based upon a private blueprint [19:28] if people's expectations are that proposing would open this to approval, but not reveal the object otherwise, we could make that possible. [19:29] Though personally, I don't know that an approved, but hidden blueprint, is anymore valuable that an unapproved and hidden one. [19:29] but sure, if this was tied into the functionality to great private meetings that would be nice. [19:29] approved would allow (as long as Summit can get the info that it needs) for the blueprint to make it on the meeting schedule [19:29] as a private meeting [19:29] right. which is a fair point. [19:30] but we don't have capacity to do all that extra work. [19:30] someone else will need to build on what we've done. [19:30] I'm not sure it's so broken that we need to remove the ability to link to the sprint at this point, but I'm open for arguments, obviously. [19:30] then IMO, it's a bug currently that you can propose a private blueprint to a sprint but not allow it to get on the schedule. [19:31] how hard would it be to add if bp=private hide sprint stuff [19:32] cjohnston, not that hard, but it is some work, and I'm not convinced we need to do it. let's just see what happens at this UDS. [19:34] I'm not sure that this UDS is a good test as, as you said, its beta and required to be a member of one of these projects [19:43] flacoste: hi; can we push the meeting back a bit ? [19:45] deryck: cjohnston: I don't think being linked is a bug per se: the lack of reciprocal disclosure is (the rule is, if you link something private with something less private, the private thing becomes visible to the same degree) [19:46] so then it would become a publicly viewable blueprint? [19:46] deryck: cjohnston: But for proprietary we want to prevent people making such links outside the things that the project owner controls, so that bug #2. [19:46] deryck: cjohnston: as for summit, +temp-meeting-export should DIAF and be replaced by an API call, and the API call can be authenticated by the bot, just have the summit bot be granted access to the relevant private project blueprints/bugs through access policy grants. [19:47] this is what I was thinking, when I thought it was a bot. just grant access to the bot for the blueprints you want scheduled. [19:47] lifeless: we aren't against that.. does the API stuff already exist to do that? [19:48] cjohnston: you wouldn't want the spider approach the current API has for this [19:48] cjohnston: you'd want to literally port the meeting export code to a single API call (e.g. sprint.export()) [19:48] deryck: yeah, +1. [19:49] lifeless, also, I'm not sure that I agree with the rile that the thing should gain the visibility of the thing linked, but if we've been consistent with that, I'll abide by the rule. :) [19:49] The thing that will bite you though, is the idea of linking proprietary blueprints to public sprints either needs to violate the rule for interaction of objects, or needs to disclose the existence of the blueprint and the project. [19:49] right [19:50] deryck: we're trying to be consistent with it, because it makes reasoning about UI and behaviour a /lot/ easier. [19:50] deryck: for all that it raises issues, it would have avoided disasters too - like the public/private bug dupe one. [19:50] if everything was authed, summit could gather the info, and keep the info private in Summit, if the ability existed in LP, though it sounds like it doesnt [19:51] the sort of thing that this rule solves is: [19:51] - invisible actions [19:51] - spying [19:51] - inexplicable failures (e.g. timeslot X is used. Not its not! yes it is!) [19:51] I don't disagree it solves all those issues. But it's also very easy to leak private data. And I'm not sure which is worse. [19:52] but I know we've had all these discussions before. I'm not trying to dredge them back up. [19:52] not we == lifeless/deryck but we == lp devs. [19:52] yeah :) [19:52] lifeless: i need to head off in a little less than 1h, maybe we would be better to postone to later in the week then? [19:54] flacoste: ok, tomorrow? [19:54] flacoste: or your wed, can't do later than that, on leave. [19:54] lifeless: yeah, let's do wed after the TL call [19:55] hokaydokay [20:57] wgrant: Do you think https://bugs.launchpad.net/launchpad/+bug/3456 is still an issue? (The bug title is outdated; read at least comment #1.) [20:57] <_mup_> Bug #3456: queue doctest removes security proxies

< https://launchpad.net/bugs/3456 > [20:58] I thought it was acceptable that the uploader was zopeless, though perhaps I'm wrong. === benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: ~300 [21:22] cjwatson: Not worth having a bug for [22:09] lifeless: https://lpci.wedontsleep.org/job/devel/lastFailedBuild/ hint hint [22:14] grrr at your cert [22:15] Yeah, sorry, I should fix that. [22:37] StevenK: its got crud in it: [22:37] successful: lp.services.scripts.tests.test_cronscript_enabled.TestCronscriptEnabled.test_enabled_cronscript [22:37] teskill: 186: No such process [22:37] Stopping lxc [22:37] t: lp.codehosting.vfs.tests.test_branchfs.TestLaunchpadTransportAsync.test_rmdir [22:37] see how test: lp.codehosting.vfs.tests.test_branchfs.TestLaunchpadTransportAsync.test_rmdir [22:37] and kill: 186: No such process\nStopping lxc [22:37] are intermingled [22:38] lifeless: Hmm, maybe I need to redirect stderr away? [22:38] wgrant, StevenK, wallyworld: can you see http://blog.launchpad.net/?p=3742&preview=true [22:38] StevenK: stderr /must/ be a separate fd, is it shared with stdout atm ? [22:38] lifeless: At the moment, I'm not redirecting them at all [22:42] StevenK: can i see the config ? [22:44] lifeless: Jenkins config, builder config? Which? [22:45] yes [22:45] the jenkins project config [22:45] to start with [22:45] brb [22:49] lifeless: You should have access to configure the project on jenkins [23:11] wgrant: My test in the LP branch passes with the new lazr.restful hacked in. [23:12] StevenK: I don't have a login ? [23:13] lifeless: Login via SSO [23:13] That should work [23:15] StevenK: Great [23:15] StevenK: did you just change to concurrency=1 ? [23:15] Yes, wgrant's suggestion. [23:17] ok, so sudo /usr/local/bin/lp-setup-lxc-test lptests [23:17] is buggy [23:17] bbs, C need sme [23:18] lifeless: That is based on the example shipped in lpsetup. I can pastebin it if you wish [23:24] wgrant, wallyworld: https://code.launchpad.net/~stevenk/lazr.restful/dict-unmarshaller-none/+merge/126615 [23:29] wgrant: Do you think the test I've added is valuable? [23:31] StevenK: Hm [23:31] StevenK: Don't we care mostly about marshalling? [23:31] Unmarshalling might be useful too, but it's less important here. [23:31] The bug you're trying to fix just cares about marshalling. [23:32] No, the bug I'm fixing is about unmarshalling [23:32] It gets None and tries to unmarshall that as a dict [23:33] wgrant: And sorry, I meant the LP test, not the lazr.restful test. [23:33] Ah, in the etag, right [23:33] StevenK: Does that test fail without the lazr.restful upgrade? [23:34] It doesn't look like it'll exercise the ETag path. [23:34] Because it's unconditional. [23:41] wgrant: http://pastebin.ubuntu.com/1255044/ [23:42] Ah, so it does a conditional anyway, great. [23:45] * wallyworld sighs, another hard lockup :-( [23:45] wgrant: So it's fine? [23:46] StevenK: yes [23:47] wgrant: Can you approve the lazr.restful MP then so I can land it? [23:48] wgrant: If you think the test I've added to LP adds value, I can leave it in, or I can just bump versions.cfg and move on. === matsubara is now known as matsubara-afk [23:55] StevenK: Does marshalling None as a dict work? [23:57] wgrant: Obviously, due to the lazr.restful test [23:57] StevenK: That tests *un*marshalling. [23:58] Yeah, I should learn to read at some point. [23:58] Let me check. [23:59] >>> print dict_marshaller.marshall_from_json_data(None) [23:59] None [23:59] There's an existing test