[00:10] * StevenK stabs the uploadprocessor tests [00:11] Fill up a bunch of changes files with the same signature and different data and then a new test fails GPG verification [00:16] can has review ? [00:16] https://code.launchpad.net/~lifeless/pybars/bug-1040096/+merge/125874 [00:19] And back to fighting with gpg [00:27] wgrant: The current files specify a DSA key ID that isn't in the keyring [00:28] StevenK: Which file? [00:28] wgrant: steven@undermined:.../suite/bar_1.0-4% GNUPGHOME=../.. gpg --verify < bar_1.0-4_source.changes [00:29] gpg: WARNING: unsafe permissions on homedir `../..' [00:29] gpg: Signature made Thu 25 Jan 2007 07:02:00 AM EST using DSA key ID 6C64A8C5 [00:31] StevenK: lib/lp/testing/gpgkeys/data/foo.bar@canonical.com.sec [00:32] sec 1024D/6C64A8C5 2005-04-13 Foo Bar [00:33] (passphrase is 'test') [00:39] wgrant: Ah, thanks. [00:40] wgrant: GNUPGHOME=. gpg --import < <.sec> and then --clearsign worked [00:44] wgrant: Ah ha, actual = 'Unhandled exception processing upload: too many values to unpack' [00:44] Excellent [00:49] Haha, yeah, fileline.strip().split() -> ValueError [00:49] As you'd expect :) [00:57] lp.archiveuploader.tests.test_uploadprocessor.TestUploadProcessor.testUploadWithMalformedSectionIsRejected [00:57] Ran 1 tests with 0 failures and 0 errors in 2.382 seconds. [00:59] Do you reject it directly, or just do a split(' ', 4) and let it fail when the filename is malformed? [01:00] split(' ', 3) actually, I guess [01:00] I catch the ValueError and yield UploadError [01:17] wgrant: https://code.launchpad.net/~stevenk/launchpad/deal-with-badly-formed-section/+merge/125908 [01:18] wallyworld_: I'd ask you to review that branch, but you'd see 'lib/lp/archiveuploader' in the diff and run screaming. :-) [01:25] StevenK: Looking [01:46] StevenK: sorry, was buying lunch, otherwise would have looked [01:47] wallyworld_: It's all good, I was only teasing you [01:47] I should go and buy part of my lunch [01:47] Otherwise I'll be having toasted turkey sandwiches with no bread [02:24] wgrant: Oh haha. I bet I know what is causing bug 899123 [02:24] <_mup_> Bug #899123: IntegrityError raised deleting a series < https://launchpad.net/bugs/899123 > [02:28] StevenK: Hm? [02:28] StevenK: It' [02:28] s pretty clear what the problem is. [02:29] wgrant: Oh? My thought is bugtasks that self.user can't see, so don't get returned so the milestone can be cleared [02:30] StevenK: Exactly [02:30] The product the series is on gives it away [02:31] Oh, I read the code to deduce that [02:31] The fact that the code is in lib/lp/registry/browser/__init__.py makes me sad [03:12] wgrant: just because i know you'll understand my pain [03:12] Aggregate (cost=1996.76..1996.77 rows=1 width=0) (actual time=449033.137..449033.137 rows=1 loops=1) [03:12] i suspect this estimate of being slightly inaccurate [03:12] Heh [03:13] Django amuses me [03:13] The schema style it encourages introduces a lot of potential planning issues [03:17] fortunately i have already rewritten this query [03:28] /win 94 [03:49] StevenK: wgrant: fancy a quickie? https://code.launchpad.net/~wallyworld/launchpad/bug-sharing-policy-weirdness-1055250/+merge/125916 [03:50] With you? [03:50] yes! [03:51] wallyworld_: You can't use setB{ug,ranch}SharingPolicy ? [03:51] where? test? [03:51] Yeah, in the tests [03:52] using setXXX() in the tests errors because it tries to create another commercial subscription and do other things we don't care about [03:52] Create? I thought it checked them [03:53] creating a project with private sharing policy creates a subscription at the same time [03:53] in the factory [03:54] i guess setXXX() should behave properly if there's already a subscription [03:54] wallyworld_: setB{ug,ranch}SharingPolicy will work fine if you're tossing in FORBIDDEN, read the code. [03:55] yes, i wonder why i got an error then, i'll retry [03:57] wgrant: So would user=ILaunchpadCelebrites.admin in RegistryDeleteViewMixin._getBugtasks cause me to get murdered? [03:58] StevenK: i must have been on crack or something. works. changes pushed [04:00] StevenK: I think so, yeah [04:00] wgrant: :-( [04:00] If you have no other choice, then maybe [04:00] I think my other choice is store.find(BugTask, BugTask.milestone == ...) but conjoined masters foul that up [04:01] StevenK: Or to give bugtasksearch an option to not do privacy checks [04:02] wgrant: Which I've not seen in my searching. [04:03] Right, you probably need to add such a feature === Ursinha is now known as Ursinha-afk [04:08] we probably should upgrade the oops-tools on lp-oops [04:08] or give it a quiet death [04:10] If we can import the oops in lp-oops into oops, then we can shoot it [04:10] or we could just let them go away [04:11] Sure, let's make a bunch of criticals more useless, what could possibly go wrong. [04:15] wel [04:15] how often do you reference them [04:15] and how often have they stopped happening entirely? [04:16] lifeless: There are a large number of critical bugs that include an OOPS and very little else. Some of these OOPSes can not be found at all, and others are only on lp-oops. [04:17] This OOPS happened once and hasn't occured for two years and yet we have a Critical open with no useful content. [04:17] so, close the critical [04:18] if the critical is an oops or timeout [04:18] the report will tell us if it happens again [04:19] lifeless: Bug 893576 is a good example [04:19] <_mup_> Bug #893576: AttributeError: 'SourcePackageRecipeRequestDailyBuildView' object has no attribute 'index' < https://launchpad.net/bugs/893576 > [04:24] StevenK: its on neither server? [04:24] wgrant: StevenK: when a commercial voucher is redeemed, i would expect the bug/branch sharing policies to be set to proprietary automatically rather than requiring the maintainer to go to +sharing to update. from what i can tell, this doesn't happen. do we want to fix? [04:24] lifeless: Right [04:25] wallyworld_: Not exactly [04:25] wallyworld_: The normal use case is that someone creates a project as Other/Proprietary [04:25] lifeless: I'm struggling to find a bug that has an OOPS that is on lp-oops but not oops, but they do exist, and their content level is about the same as that bug. [04:25] So they automatically get Proprietary [04:26] wgrant: sure, but when the subscription expires and then extended [04:26] is the case i'm talking sbout [04:26] StevenK: so, I would grep for the error [04:26] we don't reset the policies from forbidden (or public) back to proprietary [04:26] wallyworld_: That's really rare and easy for them to fix manually, and we can't do it unambiguously, so probably not [04:26] e.g. [04:26] oops-amqp/launchpad/production$ grep SourcePackageRecipeRequestDailyBuildView . -r [04:27] if its not there, close the bug - its not happening enough to worry about for now [04:27] The bug is still there [04:27] And it's trivial to reproduce [04:27] wgrant: but it mirrors the concerns about leaking info. if they extend the subscription, they would rightly expect stuff to be private from then on. but it won't be unless they do something [04:28] wgrant: thats good then, you can fixup the bug [04:28] wallyworld_: eg. ubuntuone-servers is Other/Proprietary [04:28] wallyworld_: But the bugs are usually public [04:28] wgrant: or push a branch [04:28] wgrant: I'm just saying that we have 2K errors a day, stressing about data for something with an incident rate < 1/2 weeks is not worth doing [04:28] wallyworld_: Sure, and it'll tell them they need to go to +sharing to fix it [04:28] wgrant: Then please link a proper OOPS to the bug :_0 [04:28] thats 1 every 2 weeks. [04:29] StevenK: I have === almaisan-away is now known as al-maisan [04:29] But it's literally as trivial as it can get [04:29] Just go to the pageid referenced in the OOPS [04:29] wgrant: we are now arguing different sides of the same thing we were discussing last week [04:29] boom [04:29] wallyworld_: My argument last week was primarily based on the fact that it is dangerous to leak things [04:29] This won't leak things [04:29] It will reject them [04:29] yes it will [04:29] Oh, let me guess +request-daily-build only wants POST [04:29] if they have changed to public [04:30] wgrant: that oops wasn't readable [04:30] wallyworld_: If they set it to Public then they probably want it Public... [04:30] was it ? [04:30] AttributeError: 'SourcePackageRecipeRequestDailyBuildView' object has no attribute 'index' [04:30] ^^ that is the pageid [04:30] wgrant: they will rightly expect getting s new subscription will make things proproetary sgasin [04:30] Well, no actual pageid [04:30] But view name [04:30] wallyworld_: Why? [04:30] why not? i would [04:30] They explicitly set it to Public after the subscription expired [04:31] sure, asnd then thry buy another subscription [04:31] so they expect things to go back to provate [04:31] The reactivation page could hint that it hasn't changed your existing settings [04:31] reasonable expectation [04:31] It probably should do that, in fact, for when projects initially obtain a commercial subscription === al-maisan is now known as almaisan-away [04:31] But we shouldn't just override what they asked us to do 5 minutes ago [04:31] WTF: bzr: ERROR: Permission denied: "Cannot create 'add-maas-cluster-packaging'. Only Bazaar branches are allowed." [04:31] bigjools: Your URL is bad [04:31] wgrant: no orccurences of that oops on neem prod [04:32] wgrant: hmmm. i wonder if we can tell the difference [04:32] i'll raise a bug and we can discuss on the call [04:32] wallyworld_: Which difference? [04:32] wgrant: the branch already exists, I am pushing an update [04:32] tomorrow [04:32] wallyworld_: In neither case do we want to do it automatically. [04:32] bigjools: What's the URL? [04:32] oh wait [04:32] wgrant: i disagree [04:32] fuck sake [04:32] wallyworld_: The voucher redemption page should certainly point to +sharing [04:32] But to change it automatically? That's pretty strange. [04:32] the difference between initially getting a subscription and extending one [04:33] why? [04:33] wgrant: thanks, pebkac, but you pointed me in the right direction [04:33] Heh [04:33] hint: moving branches to a subdir confuses bzr :) [04:33] wallyworld_: Just because my code is proprietary doesn't meant that my bugs are. [04:33] For ease of setup we do make that policy decision, once, at project creation [04:34] We never set the sharing policies ourselves ever again, *except* for setting them to Forbidden when a subscription expires [04:34] In all other situations we do what the project owner asked. [04:34] StevenK: so - if the oops doesn't exist on eithe rserver, try wgrants heuristic if you have a view, try grepping for the view or its base r something on neem, and then close. [04:34] StevenK: diminishing returns after that, we're not doing a NASA. [04:34] wgrant: but we can leak info because the project owner would have rightful expectstion thast extending a subscription would make stuff proprietary again [04:35] lifeless: But if you want to destroy lp-oops and free up CPU time on carob, go ahead [04:35] wallyworld_: That's extremely debatable if they're previously explicitly set it to Public. [04:35] not to me [04:35] i would expect it [04:35] wallyworld_: The commercial subscription documentation has always made clear that it doesn't implicitly turn on privacy features [04:35] since it was only set to public to reset the forbidden [04:35] It just enables you to configure them [04:35] until they got to buy a new subscription [04:35] wallyworld_: If your stuff is proprietary and you set your policies to public, then you are really really stupid. [04:36] well, i argued the same thing last week [04:36] Huh? [04:36] No, last week you argued it was really really stupid and we could do whatever we wanted just because you ignored an expiry email [04:36] I argued that we couldn't [04:36] Now I'm arguing that we can respect Public if they project owner set Public. [04:36] There's no inconsistency in my position. [04:37] fsvo [04:37] it depends on project owner expectations [04:37] OK [04:37] Why would you set it to Public? [04:37] mine would be that buying a subscription makes stuff private [04:37] That's something that has never been true. [04:38] And we never state that [04:38] And it doesn't always make sense. [04:38] We make it clear that you need to configure your project's privacy options. [04:38] hmm. ok. if it's never been true, then i guess no need to change. but i find it strange we do it that way [04:38] Now, yes, it was pretty strange that the default for a new proprietary project was for everything to public. [04:38] And we fixed that default. [04:39] i see extending a subscription in the same light [04:39] I'm Product Strategy [04:39] I want to have proprietary bugs and branches on Unity so I can perform my nefarious freedom-hating deeds in secret [04:39] Now, the project is currently listed as GPL [04:39] * ajmitch quotes out of context [04:40] But I need a commercial subscription, so I buy and activate it [04:40] Now all the random user bugs and branches are Proprietary because Launchpad changed something without asking me :( [04:40] no, that's exactly what i would expect [04:40] as the owner who bought the subscription [04:41] because i was the one who bought the subscription expecting to hsve private stuff [04:41] Expecting to have private stuff. [04:41] i guess you and i have different expectstions [04:41] Not expecting everything to be forced private despite me saying yesterday that it was public by default. [04:41] i would have only said that yesterday because i hadn't decided to buy a subscription yet [04:41] No [04:42] Unity wants "Public, can be proprietary" for bugs and branches [04:42] but once i make the decison to prchase, i want proproertary [04:42] and even if i didn't it's best to fail closed as you said last week [04:43] easy to make a few things public again than the other way round [04:43] If we're unilaterally making a change then we have to fail closed. [04:43] It's far better for everyone if we can avoid making a change at all [04:43] but buying a subscription is a change [04:43] In general, users will be less surprised if we do what they say [04:44] "buying commercial subscription" != "making project private" [04:44] yes, and to me, buying a subscription carries certain expectations [04:44] Then we need to fix the pages to make it clear that those expectations are false. [04:44] wallyworld_: So, you have a public product with public bugs and branches. [04:44] yes, i but now i want to buy a subscriotion [04:44] wallyworld_: You buy a subscription since you want to have some work be private until you're ready to release it. [04:45] yes [04:45] wallyworld_: So now all the current stuff is all private? Does not make sense. [04:45] no, not the existing stuff [04:45] new stuff [04:45] You don't want new stuff all private too [04:45] stuff i create *after* i buy the subscription [04:45] Just selected stuff [04:46] wallyworld_: Since not all new work is going to be on the private work [04:46] yes, but branches need to be proprietary by default [04:46] Buying a Launchpad commercial subscription means you get to use proprietary features. [04:46] No, they don't [04:46] That's all it does. [04:47] wallyworld_: So, you put up a bug fix branch for the released work. It should be public, why did LP create it as private? [04:47] better to do that than leak info [04:47] this would be easier using voice, let's discuss tomorrow [04:47] I agree with wgrant, fwiw [04:47] Sure [04:48] as a customer, i guess my expectations are different to yours [04:48] wallyworld_: Ask thumper what he would expect [04:48] thumper wrote branch privacy [04:48] He's probably not a good person to ask :) [04:48] Hahah [04:49] wgrant: So, IntegrityError: update or delete on table "milestone" violates foreign key constraint "bugtask__product__milestone__fk" on table "bugtask" [04:49] (From a test I wrote) [04:49] Great. [04:49] Now to find the user bit in search_bugs again [04:49] wallyworld_: We certainly need to rewrite the commercial views, emails and documentation to make clear that you probably want to visit +sharing [04:49] But I don't think making the change automatically is a good idea [04:50] And it's certainly not mandatory. [04:50] wgrant: but last week your argued that noone reads emails :-P [04:50] wallyworld_: My company's commercial subscription admin left the company a month after they activated the commercial subscription :( [04:50] So the expiration email that Launchpad sent to us 11 months later was gone [04:51] wallyworld_: As an aside, "Public, can be proprietary" means all new stuff should be private? [04:51] yeah, i know the argument. its the same for this new case too [04:51] StevenK: no [04:51] But the commercial subscription admin didn't leave 30 seconds after activating the subscription, so they were able to see that email, as well as the page confirming that the subscription was active. [04:52] wallyworld_: But that's what you said? [04:53] wallyworld_: You said you buy a subscription which allows you to set "Public, can be proprietary" and therefore since you'd bought a subscription all new stuff should be private [04:53] StevenK: no, i said the sharing policy should be changed from forbidden or public to proprietary when a commercial subscription is purchased or extended [04:53] There's a difference between failing open by a unilateral action from Launchpad 12 months after the other involved party interacted with us, and failing open because Launchpad respected a user's configuration and then hinted that they might want to verify it immediately after an action that could be misunderstood as automatically changing them. [04:53] sort of. human error and all that. fail open sometimes is still fail open [04:54] Sure [04:54] StevenK: does it make more sense now with the above clarification? [04:54] wallyworld_: No, but like you said, let's use voice tomorrow [04:55] ok [04:55] Failing that, I'm sure wgrant and I can fly to Brisbane to beat sense into you. [04:55] :) [04:56] i can see both sides of the coin [04:56] As can I [04:56] And your side has some good arguments [04:57] But I think it's less surprising if we do nothing and *say* that we've done nothing. [04:57] Anyway [04:57] => mumble tomorrow :) [04:57] wgrant: So, I should add ignore_privacy=False to BugTaskSearchParams [04:57] And then use that in _build_query [04:57] StevenK: Something like that [05:03] _deleteMilestone runs as the user so if we return bugtasks they can't see, they can't change them either. :-( [05:04] wgrant: I don't really want to add in rSP either [05:05] StevenK: It might have to [05:05] StevenK: Like package uploads closing bugs. [05:05] Yea [05:05] Pity [05:28] wallyworld_, wgrant: https://code.launchpad.net/~stevenk/launchpad/delete-milestone-all-bugs/+merge/125924 [05:29] rsp :-( [05:31] wallyworld_: I have little choice [05:32] StevenK: too bad. i guess rsp is used elsewhere as well where it's unavoidable [05:32] wallyworld_: I don't like it, but if all references aren't scrubbed, we get an OOPS. [05:32] StevenK: are there likely to be many bugtasks in that loop? should we look to do a bulk delete instead? [05:32] We can't do a bulk delete [05:32] We aren't deleting them [05:33] Well, we are if they're conjoined [05:33] s/delete/update [05:33] Um [05:33] Hm [05:33] Deleting tasks like that [05:33] Ew [05:33] ew [05:33] ew [05:33] It's existing code [05:33] But ew [05:34] wgrant: The correct thing to say is 'Conjoined masters. Ew. Ew. Ew. Ew. Ew.' [05:34] I think that code's probably even wrong [05:34] How does that make sense? [05:35] If we do happen to want to delete the conjoined master, the slave is still going to have the milestone set, isn't it? [05:35] I tend to close my eyes and say "LALALALA" every time someone mentions conjoined bugs [05:47] wgrant: There is a test for the conjoined master case, but I don't know. [06:01] wgrant: And I don't get the SourcePackageRecipeRequestDailyBuildView object has no index bug -- I'm guessing we don't want to render it directly [06:03] StevenK: Presumably it's never meant to try to render the form, right. [06:04] Well, there is no form [06:04] On the action, we request a build and redirect away [06:04] Right. [06:05] Which I'm guessing it means it was POST'd to, so I should redirect to the recipe in initialize() if it's GET? [06:06] Or potentially remove the view and replace it with an API call [06:06] I'm not sure what the view does. [06:06] Haha [06:06] Hm? [06:06] It does AJAX stuff [06:06] I'm completely serious [06:06] If it doesn't do anything special, it can probably be an API call. [06:08] wgrant: There is some JS that POSTs to it directly [06:08] Clearly. [06:08] But why is it not an API call? [06:09] It gets the AJAX stuff back and uses it to update the page [06:09] Aha [06:14] don't we have an html representation thingy in the API ? [06:14] its terrible but it exsists [06:19] We do [06:19] I'm not sure it's immensely useful here [06:19] It probably wants to get the entire build table back [06:21] hmm [06:21] if only we had some sort of client side template system [06:21] Indeed! [06:22] requestDailyBuild also may raise two exceptions which the view catches and turns into notifications [06:26] StevenK: so whats the simplest thing you can do here ? [06:27] lifeless: Add an initialize() method and redirect, like I've done [06:28] StevenK: cool [06:33] wallyworld_, wgrant: https://code.launchpad.net/~stevenk/launchpad/no-render-sprrdb/+merge/125930 [06:37] StevenK: btw, multiple tasks referencing one milestone is a model violation [06:38] StevenK: it only happens because we haven't done onlyseriestasks yet, *and* we don't do non-series milestones. [06:38] so s/is a model/should be a model/ really [06:38] lifeless: You have yet to convince people about onlyseriestasks :-) [06:41] wallyworld_: You have even more QA! [06:42] * StevenK upgrades DF, since that will take a few eons [06:54] I wonder if qas will have updated and the deployment report updated before DF finishes [07:02] yes, indeed [07:02] not used to it being so soon [07:02] Hahahaha [07:02] steven@undermined:~/ubuntu% dput dogfood:~stevenk/ppa/ubuntu xserver-xorg-video-ati_6.13.2-1ubuntu3_source.changes [07:02] Invalid Files line in .changes: [07:02] 5266cb3d554ecf973e03af8003e24932 2838 x11, foobar optional xserver-xorg-video-ati_6.13.2-1ubuntu3.dsc [07:04] StevenK: and i can just use the project i set up this morning to qa a different bug and which caused me to file and fix this one i'm doing now [07:05] mid you, i did lp-land [07:05] mind [07:05] we do need to put ec2 on steroids [07:06] wallyworld_: Go on, then. I'll wait here. :-P [07:06] there's a few options isn't there. but we really should pick one and get it done i guess [07:07] i like whatever has no more ec2 bills each month [07:07] Jenkins with parameterized builds, then [07:07] yes! [07:08] wallyworld_: Then shake lifeless until that falls out [07:08] i think if we all beat him up that will help [07:12] There, my QA is done too [07:12] What is this madness? [07:12] Bug #1055250 [07:12] qa-ok [07:12] <_mup_> Bug #1055250: Bug sharing policy weirdness on +sharing page

< https://launchpad.net/bugs/1055250 > [07:12] Reported by Ian Booth 5 hours ago [07:13] Haha [07:13] i cheated though [07:13] i skipped ec2 [07:13] wallyworld_, wgrant: Can I have a review now? https://code.launchpad.net/~stevenk/launchpad/no-render-sprrdb/+merge/125930 [07:13] sure [07:14] StevenK: when do we hit that view via a get? [07:14] wallyworld_: When people URL hack [07:14] ah, ok [07:15] It turns up every now and again [07:15] r=me [07:17] sigh. i just ran > 3000 [B|b]ug tests with an AssertionError inserted into some code and the only failure was an artificially constructed doc test. [07:18] We have some assertions commented out in Soyuz because lots of tests fall afoul of them [07:18] back to the drawing board, may need to use a soft oops to find it in prod [07:18] What are you asserting? [07:18] We may be able to neuter the test :) [07:18] i put in the assertion to try and find the cause of the issue [07:19] that the subject of a bug notification contains [Bug 123] and nothing else [07:19] <_mup_> Bug #123: There's no direct way to see the project info when translating it < https://launchpad.net/bugs/123 > [07:19] to fix bug 138775 [07:19] <_mup_> Bug #138775: Notification subject included bug number but no summary for 'subscriber of duplicate' bug notifications