[01:10] wallyworld__, wgrant: https://code.launchpad.net/~stevenk/launchpad/destroy-bfj-on-branch-delete/+merge/124828 [01:11] StevenK: any reason not to update the cascade? [01:11] so everything is in one spot [01:11] wallyworld__: BFJ deals with far more than just TTBs === Ursinha` is now known as Ursinha [01:12] seems ok to me but i have limited bfj foo === Ursinha is now known as Guest7533 [01:14] StevenK: are there orphaned db records that need to be removed also? [01:14] from previous deletes? [01:14] There are. [01:14] i guess i bit of sql would do [01:15] Yeah, just reaching for mawson [01:15] r=me anyway [01:16] And trying to work out just how evil this query will be, since we need to pull in SourcePackageRecipeBuild, BinaryPackageBuild and TranslationTemplatesBuild [01:19] sounds just peachy [01:19] SELECT id FROM buildfarmjob WHERE id NOT IN (SELECT build_farm_job FROM packagebuild UNION SELECT build_farm_job FROM translationtemplatesbuild); is pretty close, but it will take a few eons on prod [01:29] :-( [01:29] All 3 columns are indexed and it's horribly slow [01:30] I think the UNION is not helping in the slightest [01:31] Ah, two Seq Scans. Thanks, postgres [01:33] StevenK: No, it's pretty easy [01:33] StevenK: Just query for BFJs of the TTBJ type that have no TTB [01:35] StevenK: Given the potentially very large number of BFJs that could be returned, it may be best to query the IDs directly. [01:35] store.find((BuildFarmJob.id,), ...) [01:35] wgrant: I tried (BuildFarmJob.id,), but I was not loved [01:35] That's not very helpful [01:35] I've not tossed it at ec2 yet, let me see [01:36] Also, I'm not a huge fan of that test. I'd prefer that the existing TTB deletion test be extended to check that the BFJs are gon [01:36] Checking that nothing shows up on +history is very indirect and likely to incorrectly pass for a multitude of other reasons. [01:36] I made sure it broke before I fixed it [01:37] Sure, but it could also pass because the builder doesn't show the build for some reason [01:37] It's not what you really want to test [01:37] It's about the most indirect integration test you could ever think of [01:37] There must be an existing test that TTBs are deleted, so just extend that to check that the BFJs are gone too [01:38] And delete your other new test. [01:38] This is an example of our terrible doctest style, except with unit tests instead. [01:38] "unit" tests === Guest7533 is now known as Ursula [01:41] launchpad_dogfood=# SELECT COUNT(*) FROM (SELECT id FROM buildfarmjob WHERE job_type = 4 EXCEPT SELECT build_farm_job FROM translationtemplatesbuild) AS donotcare; [01:42] count [01:42] ------- [01:42] 303 [01:42] (1 row) [01:42] What was the timing on that? [01:43] Slightly under 2s [01:44] So select that into a temp table and then DELETE FROM buildfarmjob WHERE id IN tempfoobar; ? [01:44] Temp table? Surely you jest. [01:45] launchpad_dogfood=# DELETE FROM buildfarmjob WHERE id IN (SELECT id FROM buildfarmjob WHERE job_type = 4 EXCEPT SELECT build_farm_job FROM translationtemplatesbuild); [01:45] DELETE 303 [01:45] Time: 3874.078 ms [01:45] There'll be more on prod [01:45] But prod is also not running off 1rpm disks [01:45] Hahaha [01:50] Bleh, list(store.find((BuildFarmJob.id,), ...) is giving me a list of 1-tuples [01:54] StevenK: Yeah, you'll need to map it through attrgetter [01:55] * wgrant wanders out to lunch for a while === matsubara is now known as matsubara-afk === almaisan-away is now known as al-maisan [04:03] Hm [04:03] http://paste.ubuntu.com/1212288/ [04:03] postgres' optimiser makes me sad [04:03] wgrant: attrgetter doesn't work for tuples [04:03] It won't optimise "BugTaskFlat.bug IN (foo) OR BugTaskFlat.bug IN (bar)" down to "BugTaskFlat.bug IN (foo UNION ALL bar)" [04:03] StevenK: I meant itemgetter of course. [04:05] Maybe we should then [04:07] wgrant: http://pastebin.ubuntu.com/1212297/ [04:08] StevenK: I guess a list comprehension is actually probably nicer in this case, since we don't need to use DRS [04:09] But the test changes look good [04:09] Although assertEqual(0, bfjs.count()) or assertContentEqual([], bfjs) is nicer than listifying. [04:10] wgrant: http://pastebin.ubuntu.com/1212299/ then [04:13] StevenK: Sounds good === al-maisan is now known as almaisan-away [04:34] wgrant: So, how do I QA my merge fix :-( [04:34] StevenK: I believe I outlined in the bug exactly how it happened [04:34] StevenK: Or perhaps I outlined on IRC and someone quoted in the bug [04:34] I don't quite remember [04:35] wgrant: You did, indeed [04:35] wgrant: I don't quite want to delete the only account I have on qas :-) [04:36] Ah [04:36] I have a few test SSO accounts [04:36] wgrant: So, wrong question. I'd like to QA it, but I have one Person and I'd rather they weren't deleted. [04:37] wallyworld__: Does your MP about er MPs need reviewing? [04:37] StevenK: wtf not [04:37] thanks [04:37] bigjools forced me to do it [04:38] I'd rather the commit message wasn't included at all if it isn't set. [04:38] yeah, but i didn't want to introduce a different template [04:38] shut up gollum [04:38] Keep %(commit_message)s in the template, and have it expand to '' if the commit message is blank [04:39] bigjools: Why gollum? [04:39] there would still be the header [04:39] *precious* [04:39] StevenK: separated at birth [04:40] *score* [04:40] wallyworld__: Remove the header, and include 'Commit message:\n' in commit_message if proposal.commit_message [04:40] thought you would say that :-) [04:41] ok, will do. i was thinking that it may be good to see that they didn't specify a comment explicitly [04:41] wallyworld__: You may need to test to make sure there isn't \n\n\n in the mail [04:42] I'm unclear how bad the templating is, it's a been a while since I've touched it [04:42] maybe. i'll see what other tests are there for similar things [04:42] wallyworld__: There's a mail template when you subscribe someone to a P3A, I think that does similar tricks [04:43] Soyuz upload notifications use that extensively too [04:43] wallyworld__ doesn't like touching Soyuz :-P [04:43] if i get drunk enough i might [04:45] wgrant: Can haz account or are you sorting one out? [04:46] StevenK: It may be useful for you to invest in one or two spare SSO accounts [04:47] wgrant: I thought you enjoyed being the only LP engineer that has more than one? [04:47] Heh [04:54] wallyworld__: Parts of the IPerson launchpad.LimitedView adapter permit access if the user can see the team itself or any of its super teams, while others require that it be the team itself. Do you recall it was done like that? [04:54] It doesn't seem particularly valuable to preserve, but I'm not sure if I'm missing a reason it's done both ways. [04:54] wgrant: i can't recall any reason for that, or even if it were considered. it may have been an accidental inconsistency [04:55] k [04:55] StevenK: diff updated [05:23] wgrant: Your URL for bug 1019218 doesn't reproduce on qas, which is a little sad. [05:23] <_mup_> Bug #1019218: InconsistentBuildFarmJobError: Could not find all the related specific jobs at Builder:+history < https://launchpad.net/bugs/1019218 > [05:26] StevenK: The branch probably hasn't been deleted yet. [05:26] StevenK: You can probably see the actual branch listed there [05:26] I don't know which branch it was [05:27] Translation template build for lp://qastaging/guvcview [05:27] I think [05:31] That branch exists on prod too [05:35] StevenK: The creation dates and unique_names are suspiciously different [05:35] Heh, right [05:36] I don't really care about which orphaned BFJ it is [06:04] wgrant: i'm confused about the comments mentioning private_bugs and deactivating proprietary projects - i didn't change those bits at all from what was already there [06:06] Oh, I missed that the private_bugs bit was already there [06:06] But I was aware of the existing deactivation [06:06] the bug report didn't seem to imply a new enum was required [06:06] It's not clear it still makes sense to deactivate, but it mihgt. [06:07] it just said to ensure stuff couldn't be abused [06:07] We need to ensure stuff can't be abused [06:07] But we also need to not be reckless. [06:07] And changing the default to public is reckless :) [06:07] how so? it's just he default? [06:07] The plan that sinzui and I discussed on the call two weeks ago is to add a new sharing policy that allows nothing [06:07] existing stuff remains private [06:07] How is it not reckless? [06:07] My project expires, but I don't notice [06:08] I push up my proprietary code [06:08] why, you get an email? [06:08] Now my code is public :( [06:08] several emails in fact [06:08] I'm not the project owner [06:08] the owner should take responsibility for their own projects. but anyway, it's moot i guess [06:09] Silently opening up access is really really really not a good policy [06:09] it's not silent [06:09] I guess it's not truly silent [06:09] But it's still really not good [06:09] well, no pay, no privacy seems fair [06:09] Sure [06:09] can't expect something for nothing [06:09] Bu no pay, we'll make all your code public, is not fair [06:09] but it's not "all your code" [06:10] it's code pushed *after* you have lost the right for privacy [06:10] But I don't know that I've lost that right [06:10] Or I have forgotten [06:11] for new stuff, yes because you owe money [06:11] Launchpad needs to make mistakes difficult and explicit [06:11] Not make them itself [06:11] and get get plenty of warning, or the owner does [06:11] cutting off a feature when payment expires is not making a mistake [06:13] so this forbidden type should disallow creation of all new private bugs and branches? [06:13] All new bugs and branches [06:13] public too? [06:13] really? [06:13] It's not just cutting off a feature: it's opting you into a new feature without asking [06:13] Well [06:13] For branches it's the same thingf [06:13] You can't create branches with a non-default information type [06:13] For bugs it's less clear [06:14] it's not without asking - try not paying your electricity bil and see how you get on [06:14] If I don't pay my electricity bill then the company doesn't come and throw all my stuff out onto the street. [06:14] and neither do we, why do you keep claiming that? [06:14] exisiting private stuff stays private [06:15] And then I push my code and it becomes public [06:15] as expected [06:15] Why is it expected? [06:15] no pay = no more electricity, np pay = no more privacy [06:16] totally expected. don't pay for something, don't get the service [06:16] The former is temporary and fixable, the latter is not [06:16] and lots of emails about it before hand [06:16] wallyworld__: We all agreed that what wgrant is saying is the right approach [06:17] It was covered on a call about two weeks ago, I think [06:17] hmmm. ok. clearly i forgot [06:17] i don't agree but that's just my opinion [06:18] i was mainly reacting to the assertion that *all* your stuff get's throen out onto the street so to speak [06:18] wallyworld__: I'm not sure if you were on the call, but at least myself, wgrant and sinzui agreed it was the right approach. [06:18] sure, np [06:19] i guess we have to protect people from themselves. sad but true [06:20] wallyworld__: Well, a freshly pushed branch probably contains all of your history. [06:20] So it is all your stuff. [06:20] Effectively. [06:20] wgrant: So, 1.0 API for security_contact? Please? [06:20] even if it is stacked? [06:21] If the project uses stacking then it's a bit different [06:21] But sadly lots of our commercial projects don't. [06:21] (because they have lots of codebases living in a single project. which we don't really support, but they do anyway) [06:22] But not supporting something and being reckless with security are unfortunately different. [07:53] good morning [08:00] morning === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === matsubara-afk is now known as matsubara [12:40] rick_h__: I didn't get to https://code.launchpad.net/~rharding/launchpad/move_into_utils/+merge/124678 until late yesterday and it was "Work in progress". Is that right? [12:40] benji: yes, it gained some scope [12:40] benji: so yea, I ping'd you to ignore it. Sorry for the trouble [12:40] no worries [12:59] sinzui: ping, trying to figure out a conflict here with doc/message-holds.txt? I don't see it blown away in your doctest purge [13:00] rick_h_it was [13:01] sinzui: ok, then I'll just remove it locally/resolve. It wasn't listed in http://bazaar.launchpad.net/~sinzui/launchpad/angy-mob-burns-doctests/changes so trying to make sure I resolve this right [13:02] rick_h_, I see it in the act in trunk: http://pastebin.ubuntu.com/1212860/ [13:03] sinzui: ok cool === rick_h__ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: rick_h | Firefighting: - | Critical bugs: ∞ [13:15] sinzui: another ping, reviewing https://code.launchpad.net/~sinzui/launchpad/delete-packaging-link/+merge/124809 and not understanding the adding of the karma bits in the test file. Was it required for some reason? [13:16] rick_h_karma will make the user non-probationary...a user with experience [13:16] I think that needs a comment [13:16] sinzui: ah, that makes total sense. Thanks [13:17] rick_h_I keep forgetting you review on Tuesdays. I have it in my head this day is empty [13:17] I took 3 reviews this morning thinking that [13:18] sinzui: yea, that's ok. You pushed me. I wanted to try to get one branch into ec2 before reviews this morning so trying to out race you :P === slank` is now known as slank === slank is now known as Guest61577 === mbarnett` is now known as mbarnett [14:23] rick_h_: as of 3.5.1, Y.Array.forEach is part of yui-base. Tempted to retain it because forEach is the official ECMAScript spelling: http://ecma-international.org/ecma-262/5.1/#sec-15.4.4.18 [14:23] abentley: ok, then yea including array-extras will allow that to work [15:30] gary_poster, yellow squad: Do you have a moment to help with lxc? lxc-start-ephemeral is hanging all the time, even with a freshly created base container. Have you encountered this? [15:34] hi allenap. we are sprinting this week, so we ideally are focusing here. hallyn on #ubuntu-server has been very helpful for us in the past. I'm looking myself. hazmat suggests lxc-start may be the problem. The first thing I can think of is to make sure that you can start the base container. Have you confirmed that? [15:35] allenap, another idea is to actually modify the script (it is just a shell script) to have set -x at the top, to show you what command is hanging [15:37] gary_poster: Tip top, thanks for that advice. Looks like lxc-net was broken/not running. I have yet to discover why. Have a good sprint! [15:38] thanks allenap :-) === matsubara is now known as matsubara-lunch === deryck is now known as deryck[lunch] [16:33] rick_h_: could you please review this MP: https://code.launchpad.net/~adeuring/launchpad/specifications-sharing-service/+merge/124978 ? [16:34] adeuring: sure thing [16:34] thanks! [16:35] adeuring: #96 says + @operation_returns_collection_of(IBranch) [16:35] but this is specifications right? [16:36] rick_h_: argh, of course, I'll change it [16:37] adeuring: same with the docstring that mentions branches please [16:37] sure [16:39] sinzui: I'm confused, because I see there's an accesspolicy.person column, but you say "They do not have any form of access policy". [16:49] adeuring: r=me after the s/branch/specification and a wonder if we should have a bug/XXX for coming back to it later or not. [16:50] rick_h_thanks, change already done. Regarding the XXX, I think we should at first see how slow the query will relly be. [16:50] abentley, it is incomplete. [16:51] sinzui: Ah, okay. [16:51] adeuring: ok, cool. Wanted to bring it up. [16:53] abentley, we do not know how exactly to manage who may know of the team, or see extra information about it :(. We know archive subscriptions grant limited view, but how would I say all canonical staff may know about our private tech team? [16:54] sinzui: ISTM that an AcccessArtifactGrant would be the way to go. [16:54] I think there was some confusion about requirements too. wgrant does not think the issue can be solved until private projects are in beta, but most private teams are not associated with projects...I don't see the connection [16:55] abentley, I think we might need to do that (mirror the project schema). bug 1014580 is ultimately caused by private team in places that we know implicitly allow users to know about the team, but Lp has no means to verify that [16:55] <_mup_> Bug #1014580: MixedVisibility error in ProductSet:+all and Product:+index pages

< https://launchpad.net/bugs/1014580 > === matsubara-lunch is now known as matsubara [17:18] do I need to request a review of lp:~stefanor/launchpad/edit-packagesets? or will an on call reviewer get to it at some point? [17:18] tumbleweed: so I was peeking at it but it's way out of my wheel house [17:19] tumbleweed: so I am going to wait until wgrant and SteveK get up and ask them to look [17:19] thanks === deryck[lunch] is now known as deryck [18:23] rick_h__: can you take a look at https://code.launchpad.net/~jcsackett/launchpad/too-many-findAP-methods/+merge/125011 [18:25] jcsackett: will do [18:26] jcsackett: r=me [18:26] yay for killing cruft [18:27] rick_h__: thanks. [19:46] deryck: yay! productjs branch passed ec2 tests! Thanks again for helping figure that crap out [19:46] rick_h__, np! Glad it worked. === rick_h__ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: ∞ === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [20:11] deryck: Any chance you could review https://code.launchpad.net/~abentley/launchpad/spec-creation-js/+merge/125038 ? [20:11] abentley, sure. [20:26] lifeless: ever stumbled upon http://www.12factor.net ? [20:27] yes [20:27] a lot of these principles seems to be dead on for a SOA architecture [20:27] elliot linked it in G+ [20:27] I think its pretty good [20:29] should we link it from the Services page? === Guest61577 is now known as slank === slank is now known as Guest70664 [20:37] flacoste: yeah, might be good [20:41] deryck: On Kanban, is "Blueprint specs should honour sharing policy" the same as "Use sharing policy default for creating specs"? [20:41] abentley, yeah, they are. sorry if I duped that. [20:42] deryck: np, just wanted confirmation before deleting. [20:47] deryck: I think someone also pointed out that blueprints were accepting information_types that violated the sharing policy, e.g. PUBLIC for a PROPRIETARY product. [20:49] abentley, ah, ok. via the API? [20:49] deryck: No, via the UI. [20:49] abentley, is there a bug? [20:51] abentley, also, I still don't have a diff on that MP. something up there? [20:51] deryck: I can't remember whether I saw it on a bug report. [20:51] abentley, ok, I'll make a note and check into it. [20:52] that surprises me a bit actually. [20:54] lifeless, hi there. do you have strong opinions about the visibility vs information_type thread? Or are you happy for sinzui and us to chat it out? [20:54] you and sinzui should come to consensus [20:54] awesome, thanks. [20:54] if you need a tie break, I will be happy to do so. [20:56] deryck: it timed out: https://oops.canonical.com/?oopsid=OOPS-469a5d735141f9e84163c03ce55e9d4d [20:56] deryck, I am satisfied with the discussion. I think your argument are right [20:56] deryck: I tried triggering a new scan. No results so far. [20:57] thanks, sinzui. I appreciate you weighing in on it and discussing it with me and abentley. [20:59] abentley, I can't see the ooops yet due to two-factor auth issues, but I had a branch like that last week. had to push to a new branch on lp and re-MP. [21:01] deryck: Here is the diff: http://pastebin.ubuntu.com/1213706/ [21:02] abentley, thanks. [21:02] abentley, I'll review this evening unless you're really wanting to get it landing here shortly. [21:03] deryck: That's cool. [21:03] abentley, thanks. I have smoked chicken to order soonish here. ;) [21:04] wgrant: StevenK ping when you get get in. I left a review about packagesets I didn't feel I knew enough to go over well and respond to his edge case concerns. Can one of you take that please? [21:04] and with that...time to run! [21:09] later on everyone.... [21:09] later gator [22:07] rick_h__: Sure === matsubara is now known as matsubara-afk [23:28] thanks wgrant