[01:28] wgrant: Your card for respecting BugSharingPolicy is in review. Is it really in review? [01:30] I submitted an MP last night... [01:30] but it doesn't seem to be there [01:30] maybe I had too many MPs open and it hung and I didn't notice [01:30] oops [01:30] * wgrant will resubmit shortly [01:37] wallyworld, wgrant: https://code.launchpad.net/~stevenk/launchpad/destroy-target-uses-malone/+merge/121958 [01:39] looks ok to me [01:59] official_malone is still a bit evil, but less so than target_uses_malone [02:07] https://bugs.launchpad.net/launchpad/+bug/1043591 makes me happy [02:07] Private security bug with notifications but no security contact [02:09] Linux Mint 12 and he's filing it in LP against LP? :-( [02:10] wgrant: We can't destroy the team until the DB patch is on prod? [02:11] StevenK: And it's all that gives us access to a few private bugs in other projects [02:12] But sharing! We can fix it [02:13] wallyworld: Is your branch that creates sharing policies on creation up? [02:14] It's in buildbot [02:14] StevenK: in bb [02:14] It's landed, so fine, I'm not blocked by it to fix bug 1043366 [02:14] <_mup_> Bug #1043366: Create Private and Private Security policies if sharing policy allows them < https://launchpad.net/bugs/1043366 > [04:23] * StevenK smacks wallyworld for duplicated code. [04:24] where? [04:24] setB{ug,ranch}SharingPolicy [04:24] I've refactored it out [04:25] i wasn't the original author [04:25] blame wgrant [04:25] I wrote them originally and they were like two lines each [04:25] Then sinzui and I added to them [04:25] And now they're probably worth refactoring [04:26] yes. best to to try and generalise too early [04:26] * wallyworld smakes StevenK for jumping to conclusions :-P [04:27] Particularly now that they're becoming more sensible (creating PRIVATE and PRIVATESECURITY themselves), it probably makes sense to refactor now [04:30] Bah, still +2 [04:30] However, setBugSharingPolicy is two lines, and Branch is 3 [04:30] :) [04:31] No, +3, missed an import [04:33] :( [04:34] wgrant: http://pastebin.ubuntu.com/1175144/ [04:35] mmmmmmmm [04:35] maybe [04:35] I'd prefer you moved the setattr out, really [04:36] Only saves a single line, and makes things far less greppable [04:36] +4, but the extra one is your fault. :-P [04:37] Heh [04:37] I thought test -vvt 'TestProduct$' would work :-( [04:37] That should [04:38] steven@undermined:~/launchpad/lp-branches/shift-ap-creation% bin/test -vvt 'TestProduct$' [04:38] Running tests at level 1 [04:38] Total: 0 tests, 0 failures, 0 errors in 0.000 seconds. [04:38] Oh [04:38] Well [04:38] There's no tests named that [04:38] Do you mean TestProduct\..*? [04:38] Probably [04:39] that setattr s bong anyhow [04:39] obj name value [04:40] Well, yes. [04:40] But it's also pointless so it's dead :) [04:40] lifeless: Yeah, I was going to introspect the variable's name out [04:40] side effects bad in that sort helper [04:40] And then get murdered by wgrant [04:40] I'm not that murderous today [04:41] Now to figure what is creating these APs [04:43] StevenK: Your new code probably is... [04:43] StevenK: makeLegacyProduct just unsets foo_sharing_policy afterwards [04:43] They start of as PUBLIC [04:43] off [04:44] (you'll probably need to fix createProduct to not set the to PUBLIC if it's about to override them to PROPRIETARY, too) [04:45] wgrant: The default argument is None, and makeProduct only sets them if they're not None? [04:45] StevenK: See createProduct [04:45] It defaults them to PUBLIC [04:45] Then if the license is Other/Proprietary, sets them to PROPRIETARY [04:46] Hmmm [04:46] Indeed, that is a pickle [04:47] wgrant: It doesn't actual set until after that block [04:47] bug_sharing_policy_to_use = BugSharingPolicy.PUBLIC [04:48] Oh, right [04:48] That makes more sense [04:48] But sti.ll [04:48] makeLegacyProduct will create the APs due to your new code [04:48] Because it calls createProduct [05:06] wgrant: So, did you put that card's branch up for review? [05:07] I have the final set of 20 test failures, so will repropose once those are fixed [05:09] wgrant: https://code.launchpad.net/~stevenk/launchpad/shift-ap-creation/+merge/121985 [05:09] * StevenK prepares for the wgrant sadface [05:09] D: [05:15] StevenK: Is it perhaps better to nuke the APs in the test rather than adding the skip_sharing_policy arg? [05:15] Regardless, makeLegacyProduct needs those two APs [05:15] So you cannot skip_sharing_policy unconditionally in there [05:16] wgrant: If we're just going to nuke them, the test is pointless [05:17] StevenK: Mm, true [05:18] StevenK: I guess what you want is a couple of tests for setFooSharingPolicy [05:18] Which already exist [05:18] I added the checks for APs to the bottom [05:18] Create a free project, check that it has [PRIVATE, PRIVATESECURITY], set bug_sharing_policy, confirm it creates PROPRIETARY [05:18] Create a proprietary project, check that it has PROPRIETARY, set bug_sharing_policy, confirm it creates [PRIVATE, PRIVATESECURITY] [05:22] wgrant: http://pastebin.ubuntu.com/1175188/ [05:24] StevenK: LGTM === jtv1 is now known as jtv [06:05] wgrant: StevenK: i think there's a bug in createProduct - it always creats AP for UD and PS even for sharing_policy = PROPRITARY which only allows PROPRIETARY [06:06] wallyworld_: That's what Stevenk just fixed, isn't it? [06:06] ... [06:06] wallyworld_: Read the diff on https://code.launchpad.net/~stevenk/launchpad/shift-ap-creation/+merge/121985 [06:06] oh, right. ok. i wasn't paying too much attention [06:06] OK, good [06:07] the branch i'm working on has been affected by this bug [06:07] StevenK: https://code.launchpad.net/~wgrant/launchpad/bug-restrict-type/+merge/121989 [06:07] wgrant: Fantastic, looking [06:07] There's a few hundred lines of testfixes that I haven't pushed yet, to avoid killing you [06:07] too bad [06:07] ly [06:07] Our last few final cleanup branches are all a bit intertwined :( [06:08] wgrant: +107 :-( [06:08] sigh, new code not always bad [06:09] No, just seeing if what wgrant does to me works with him. [06:09] let's see.... [06:09] * wallyworld_ gets popcorn ready [06:10] Heh [06:11] I bitch about new code on pure cleanup branches :) [06:11] sometimes cleanup requires new code [06:11] Sure [06:13] wgrant: r=me, with one comment. [06:13] sadface [06:14] Ah yes [06:14] I meant to do that, actually [06:14] Thought I caught all of them [06:14] But apparently not [06:20] wallyworld_: Ah, you're working on the SharingService bug I reported last night? [06:21] getAllowedInformationTypes, yes [06:21] Great [06:21] I think that's the last important bit [06:21] i need to introduce some new methods on IProduct, IDistro [06:21] getAllowedBranchInformationTypes() [06:21] to match getAllowedBugInformationTypes() [06:21] Yeah [06:22] I guess just push that down from BranchNamespace [06:22] ish [06:22] i just used POLICY_ALLOWED_TYPES or whatever it;s called [06:22] imported it [06:24] Right [06:24] We probably want to rename that now [06:24] to say BRANCH or something [06:24] I didn't initially expect it to be exported [06:25] Right [06:25] But it's now used in a few places [06:25] There's a bug one which is also used in a few places [06:27] wgrant: i aliased it on the import [06:27] same with P_A_T for bugs [06:27] Right, but everyone's doing that now [06:27] I'll fix it tomorrow [06:27] So we should possibly just rename it at the source [06:28] not everyone needs to branch version, just me [06:28] but yes we can rename [06:28] wallyworld_: Just alias it, I'll do a branch to just rename tomorrow [06:28] i will also need a followup branch when setting the sharing policy using the ajax popups [06:28] since i need to reset the json cache [06:28] Ah, yes [06:29] to allow for the different types [06:29] hence i need a view layer :-P [06:29] We also need to refresh parts of the sharing table, if possible [06:29] eg. if I set from Public to Proprietary, it'll add a grant for the owner on Proprietary [06:29] yes [06:29] But not show up until I refresh [06:29] will do all that next [06:30] but it all works now, i merged in StevenK's branch. just need to add tests [06:30] Great [07:40] ImportError: No module named sysconfig [07:42] oh... probably because it has a hardcoded python2.6, and we still need that for production :-/ [07:49] stub: What's that from? [07:49] Not seen it before [07:49] Running preflight locally [07:49] good morning [07:51] Ah, right [08:18] o/ === almaisan-away is now known as al-maisan [08:32] wallyworld_, StevenK: Product._ensurePolicies (as called by setFooSharingPolicy) currently creates any missing policies, and grants the owner access to all of the requested types. I wonder if we want to restrict the grants to just the new ones. Otherwise eg. changing PUBLIC to PROPRIETARY_OR_PUBLIC will grant the owner access to everything, even though only Proprietary is new [08:32] Opinions? [08:32] jelmer: any luck with bzr-2.5 on staging? [08:32] hmmm. sounds reasonable at first thought [08:32] (anything I can help with?) [08:33] wgrant: As wallyworld_ says, sounds reasonable. Bring it up on the call and the four of us can discuss it? [08:33] Or I could land the fix in 5 minutes... [08:34] Seems pretty unobjectionable [08:34] Or that [08:34] i just wonder if we are relying on ensurePolicies to correct mistakes [08:34] My fix won't land, ec2 will send hate mail [08:34] wallyworld_: I think it's more likely to cause mistakes. [08:34] But it's not huge either way [08:35] lifeless: did you see any of the conversation about lpstats? I'm thinking we just want to nuke all of the extra rabbit queue data, but I'd like sign off from someone else before we delete it. [08:35] +1 [08:35] wgrant: i guess fixing it makes things more failsafe [08:35] Oh, actually, I might have misread [08:35] It may do that already [08:35] But the variables are a bit ambiguously named [08:35] * wgrant rereads [08:35] jam: Do what needs to be done :) [08:36] wallyworld_, StevenK: Yeah, sorry, required_types had me confused. It's actually the required types that must be created [08:36] So it already has the behaviour I said [08:36] cool [08:37] Otherwise everything seems pretty nice [08:37] well, after my next 2 branches land to fix +sharing [08:37] for proprietary projects [08:38] Right [08:38] one is in review [08:38] But it's perfectly usable atm, just a few too many UI elements sometimes [08:38] that don't do anything [08:38] yeah [08:38] Tomorrow I need to analyse the damage from the buggy garbo job yesterday [08:38] there was also confusion between Private vs Proprietary [08:38] jam: if you think we'll confuse tuolumne, I'm happy to help with analysis or whatever, but I presume you looked at the structure in enough detail to avoid such side effects. [08:38] i wonder if we need to fix thsat [08:39] wallyworld_: Yeah, I've always been a little concerned about that [08:39] wgrant: buggy job? what happened? [08:39] wallyworld_: It will be less of an issue once your current fix is deployed [08:39] wallyworld_: As commercial projects will never see private [08:39] let's hope so [08:39] Currently even once they set everything to Proprietary, there are still Private and Private Security grants showing up on +sharing [08:39] https://bugs.launchpad.net/launchpad/+bug/1043319 [08:39] <_mup_> Bug #1043319: UnusedSharingPolicyPruner doesn't preserve permitted access policies

< https://launchpad.net/bugs/1043319 > [08:39] yes [08:40] ah right, that one [08:40] affected landscape [08:40] Right [08:40] And will have affected lots of non-commercial projects [08:40] Mostly by deleting their Private policies [08:40] I suspect [08:40] do we know how many commercial projects still have sharing policies needing to be set? [08:40] 540 or so [08:40] because all public projects should have been updated via garbo job [08:41] 583, sorry [08:41] yeah [08:41] https://pastebin.canonical.com/73308/ [08:41] All public projects should have been, yes [08:41] Is it in hourly? Can't remember [08:41] But it won't matter after tomorrow, as they'll be created pre-configured [08:41] houry [08:42] wgrant: so it would be considered failsafe just to update those commercial projects to policy = proprietary [08:42] id the owners don't do anythiong [08:42] Right [08:43] can't wait for that so we can nuke bvp :-) [08:43] It's likely to cause a few people to be unable to push branches [08:43] Yes :) [08:43] well, it will be a good way to shake things out :-) [08:44] because the pushers will complain to get access and the owners will have to get things correctly configured :-) [08:44] yep [08:45] * wallyworld_ hears a cork pop. mmmm. tasty drink time [08:45] heh [08:45] jam1: mgz and I have made some progress, I'm about to chuck it into ec2 again [08:45] jam1: did you see my replies ? [08:45] lifeless: yeah [08:45] jam1: kk [08:45] wgrant: so, fdt soon [08:45] wallyworld_: yup, double patch, and hopefully about 7 seconds === jam1 is now known as jam [08:45] But this is the first super-short one [08:45] So will be interesting [08:46] lifeless: thanks. [08:46] excellent. i want to land the followup devel branch :-) === ev_ is now known as ev === mpt_ is now known as mpt === al-maisan is now known as almaisan-away [10:39] hey all, could somebody help me with an issue I believe to be with the LP API? I'm trying to create language packs for Q, and the process is failing to download static translations from LP through the API. I hit a similar issue a few weeks ago when trying to build the 12.04.1 language packs, which wgrant and others helped to solve. I'm wondering if it's the same issue again. The tool that makes the API call is langpack-o-matic, running on a Canonical s [10:39] erver, could someone give me a hand debugging this and getting the langpack to build? [10:48] do you have irclog from that a few weeks ago and output for the failure now? [10:51] mgz, I can find the log, but the failure output is simply what langpack-o-matic outputs (basically interpreting "gzip: stdin: not in gzip format" in http://pastebin.ubuntu.com/1175572/ as "could not download file") [10:58] mgz, here's the IRC log from last time: http://pastebin.ubuntu.com/1175613/ [10:59] dpm: so, we're presuming we got an error page rather than a .tar.gz [10:59] that might be a timeout, but if it got bumped last time, it might not be. log doesn't have timestamps, but it didn't run any time around 10UTC did it? [11:01] mgz, it might have, let me check... [11:04] mgz, yeah, the script was started at 10:02UTC actually [11:05] hm, probably past the window [11:06] I'll try to re-run langpack-o-matic [11:06] but logging the actual response code from urlretrieve and actually checking what is fetched is a tarball would help regardless [11:06] how do you deploy code for this? can give you a patch for that quickly [11:08] mgz, MP on https://code.launchpad.net/~ubuntu-langpack/langpack-o-matic/, and I'll ping pitti as the maintainer about it [11:10] mgz, on http://bazaar.launchpad.net/~ubuntu-langpack/langpack-o-matic/main/view/head:/import#L217 [11:10] heh, urllib seems to actually chuck the status code away... === Pendulum_ is now known as Pendulum === gary_poster|away is now known as gary_poster === almaisan-away is now known as al-maisan [13:52] dpm: did rerunning the script work? [13:52] mgz, it seems it did, yes [13:54] okay, I'll file bug and fix for the error handling. seems like you just don't want to run it near launchpad downtime. [14:11] yeah, I'll try to remember that :) thanks mgz [14:16] Hey guys... on bug #1035661 Its fix released.. It's still effecting me (screenshot attached). should I open a new bug or reopen that bug? [14:16] <_mup_> Bug #1035661: group membership expire date "self renewal" can not be set: "Wrong Type" < https://launchpad.net/bugs/1035661 > === al-maisan is now known as almaisan-away === jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: jcsackett | Firefighting: - | Critical bugs: 4.0*10^2 === dpm is now known as dpm-laptop === dpm-laptop is now known as dpm === frankban_ is now known as frankban === deryck is now known as deryck[lunch] === matsubara-lunch is now known as matsubara === deryck[lunch] is now known as deryck [18:06] rick_h_: Do you know how to debug "extend failed, verify dependencies"? [18:07] abentley: it's a tough one, usually I comment out all objects/extend() in the file and open them up one by one [18:07] to find the missing dep [18:09] rick_h_: The file has no objects. It's all functions. So I'm assuming one of the dependencies, itself, is broken. [18:10] abentley: try to run the YUI test layer and see if one of them blow up to hint? [18:12] rick_h_: I guess I can try. I don't think any other files have been changed. [18:12] abentley: xvfb-run ./bin/test -x -cvv --layer=YUITestLayer should run pretty quick [18:14] rick_h_: Only failure was in my file. [18:14] abentley: can you pastebin and I can look for anything that jumps out ? [18:15] rick_h_: The source file itself? [18:15] abentley: yea, the file with the error [18:16] rick_h_: http://pastebin.ubuntu.com/1176379/ [18:21] abentley: lazr.choiceedit does that still existing? I thought it was killed [18:21] I wonder if including that requirement is causing it to fail, check the build/js/meta.js [18:21] rick_h_: It still existing. at build/js/lp/app/choiceedit/choiceedit.js [18:22] ah ok. There's some work on killing lazr and I don't see that module used in your code [18:22] rick_h_: It provides Y.ChoiceSource. [18:25] yea, see it. Is the branch pushed up to check out? [18:26] nothing jumps out in there, but wonder if it's the used location [18:26] is this in a test file? is the test file YUI() vs YUI? [18:31] rick_h_: branch is at ~abentley/launchpad/blueprint-info-type-ui and up-to-date. [18:32] rick_h_: The test runs fail with "extend failed, verify dependencies", but only if information_types.js includes lp.app.choice. [18:32] s/includes/requires [18:36] abentley: in test_information_type.html it's including information_type.js from the build directory, but then also including it via ../information_type.js [18:37] rick_h_: Ah, that's got it. [18:37] rick_h_: Human error while merging. [18:37] cool === almaisan-away is now known as al-maisan [18:38] rick_h_: Thanks very much. === al-maisan is now known as almaisan-away [20:31] jcsackett: Could you take a look at https://code.launchpad.net/~abentley/launchpad/blueprint-info-type-ui/+merge/122140? Sorry it's a bit long. [20:37] abentley: sure. [21:09] abentley: r=me, but some comments about QA on the MP. [21:09] information_type_choice has been a hotbed of accidental breakages, so it's worth your time to double check things that seem somewhat redundant. :-P === jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 4.0*10^2 [23:13] wallyworld_: I think your AP changes have caused a sampledata conflict with db-devel? Could you have a look at that soonish before PQM spams us to death, please? [23:14] sure [23:14] but i didn't change sample data? i guess there's a constraint violation [23:14] Hm [23:14] Maybe it's not your fault, then [23:14] I thought you might have prepopulated sampledata [23:15] noooo [23:15] Might just be fallout from my merge, then [23:15] * wgrant fixes [23:15] Probably related to the reverted reverted reversion [23:15] bb is ok, did you see it locally? [23:16] PQM's failing to merge [23:16] Anyway, fixing [23:17] It's indeed a criss-cross from the mismerge [23:18] Ah, I was about to look at that. [23:18] StevenK: How'd your AP creation branch go in ec2 last night? [23:19] wgrant: 4 failures, I'm starting to peer at them now. [23:20] If you fix them in a few minutes then we can massacre buildbot and deploy them today [23:20] But, oh, no pressure. :-) [23:21] Hah [23:27] wgrant: Hah. All four failures are caused by factory.makeLegacyProduct(licenses=[License.OTHER_PROPRIETARY]) and then having the bugs forced to USERDATA [23:29] StevenK: Ah, right. Maybe have makeLegacyProduct set them to PUBLIC and then unset them [23:29] to ensure the APs exist [23:30] Why? The whole reason they don't get set is because setB{ranch,ug}SharingPolicy says oh, License.OTHER_PROPRIERAY, here, have PROPRIETARY only [23:31] StevenK: Not for a legacy product [23:31] License.OTHER_PROPRIETARY is handled by createProduct [23:31] to set the sharing policies to PROPRIETARY [23:32] makeLegacyProduct then unsets them, to get the old behaviour [23:32] But it relies on the fact that the USERDATA/PRIVATESECURITY APs will exist already, because they did until your branch [23:32] Now you'll need to create them by either calling _ensurePolicies directly, or setBugSharingPolicy(PUBLIC) before setting it to None [23:33] Yeah, I get it now. [23:33] (IIRC the tests that use makeLegacyProduct with License.OTHER_PROPRIETARY are testing that owners can set private_bugs if there's a commercial sub?) [23:36] is there a way to delete a packageset? [23:36] via API [23:40] Not even sure there's one internally [23:40] There isn't one [23:40] Easy enough to add and expose if someone wants to [23:42] hmm [23:42] This causes me to reconsider how much we care about doing this [23:42] vs, say, deleting all the uploaders and leaving them [23:43] It'd be about one hour to develop, test, and write up the MP, I suspect [23:44] Agreed, just have to check that all the permissions are gone, basically [23:45] wgrant: Test failures fixed, pushing now. [23:45] Branch is now +0 [23:45] :) [23:46] possibly could be something to do on the train on Saturday morning [23:51] wgrant: r15890