[00:01] wgrant: Right, removing the Not() now has it return the owner, subscriber and the structsub, I'd expect only the first two [00:03] That should be more easily debuggable. [00:03] You'd think, but the query is defying me [00:04] wallyworld_: http://pastebin.ubuntu.com/1101068/ [00:04] * wallyworld_ looks [00:06] StevenK: yes, looks good. you may want to cast an eye over the sharing tests to ensure that all the XXXs are removed and branches are fully covered. i had a nagging feeling there was a little cleanup required, but am not sure [00:06] certainly there must be no test for the method you just fixed [00:08] wallyworld_: ping, hey that report a bug fix branch should hopefully hit QA soon. It passed buildout a while ago, but had the qa-ok tag on it still so thinking it didn't get picked up for qas [00:08] wallyworld_: can you keep an eye and try to get that ok'd if a NDT goes down tonight? [00:08] rick_h_: sure, np. what was the remaining issue [00:09] there was some additional JS that checked the pagination state to update it as required as you went from page to page [00:09] I've been tracking the deployment report [00:09] so when the navigation got updated, it locked the report a bug link back out again [00:09] the listing_navigator stuff needs to be torn to bits tbh [00:09] yuk. well at least it's fixed now [00:09] rick_h_: Which revision are waiting on? [00:10] yea, I might write up a -dev email on catching greedy selectors in review [00:10] StevenK: 15657 [00:10] Right, I'd expect the deployment report to show that in about ~ 15 [00:10] StevenK: ok cool, was trying to wait for it but I'm done I think. Appreicate it if you guys can help get that updated. [00:11] 15650 needs QA, as does 15654 and 15655 [00:11] * rick_h_ is sad that link's been broken for almost 3 days [00:15] rick_h_: don't feel too bad, shit happens === jamesh__ is now known as jamesh [01:05] StevenK: if you are working on that branch subscriptions removal job card did you want to take the card and move it to Coding? [01:09] wallyworld_: It's only because I've gotten annoyed at this structsub branch [01:09] sure :-) [01:27] Is there a way to give read-only access to a private ppa Launchpad pages? [01:29] It seems that if I subscribe a team or user to the PPA, they're able to download / install packages from the PPA but are unable to view its Launchpad pages [01:29] that's the intention [01:29] there is no r/o access to the pages [01:31] bigjools, I figured as much which turns out to be less than ideal for some of our projects [01:31] what is your use case? [01:33] bigjools, We have projects that are used as baselines for other projects, so we restrict upload rights more severely than we otherwise would. People that are associated with the project, but not entitled to upload packages, would still like to be able to view the PPA pages [01:34] timrc: ok it sounds like more work around disclosure. you could chat to the purple guys about it [01:34] bigjools, I've just made a note of the deficiency for now. I'll let smagoun push the issue if he cares too ;) [01:34] ok :) [01:34] I was just confirming that it wasn't possible to do [01:35] I don't think archive privacy is on our roadmap [01:38] Maybe I'll just suggest we use subscriptions and grep-dctrl or something for now [01:40] wallyworld_: I have an MP up for you, just waiting for the diff [01:41] ok [01:42] * wallyworld_ taps fingers, waiting.... [01:48] StevenK: i think your branch is stuck [01:49] Grr [01:50] StevenK: and you can't delete it. i usually have to push to a new branch and start again [01:53] Hm, didn't we fix branch deletion? [01:54] StevenK: not that i've noticed [01:54] it didn't work for me yesterday [01:55] :-( [01:55] when i had a stuck branch. i was going to look at doing something when on maintenance [01:55] i think a branchrevison trigger is at fault [01:55] Like deleting the branch scanner out of disgust [01:55] so branchrevision must die or at least be severely spoken to [01:55] It's not a trigger [01:55] Well [01:56] It's the ON DELETE CASCADE fk [01:56] So deleting the branch tries to delete a 120k BranchRevision rows [01:56] which takes more than a few seconds [01:56] == boom [01:56] i used the term trigger loosely :-) [01:56] Easy fix is to increase the timeout [01:56] stevenk@carob:/srv/launchpad.net-logs/production/ackee/bzrsyncd$ grep '~stevenk' scan_branches.log scan_branches.log-20120720 [01:56] stevenk@carob:/srv/launchpad.net-logs/production/ackee/bzrsyncd$ [01:56] StevenK: You fail at celery [01:56] Oh, it logs elsewhere now? [01:57] scan_branches.py logs to scan_branches.log [01:57] celery does not [01:57] It logs to celeryd-SOMETHING.log [01:57] SOMETHING is job or branch_job or something like that [01:58] Two scan branch jobs [01:58] ? [01:59] I'd expect two, indeed [02:00] Yeah, they timed out [02:01] I think branch deletion actually worked [02:18] wallyworld_: https://code.launchpad.net/~stevenk/launchpad/sharingservice-rasj-miss/+merge/115874 [02:18] diff there now [02:19] wallyworld_: It's a different MP. Different branch, too [02:19] I pushed, and waited for Branch:+index to show the revisions before proposing [02:19] yeah, found it [02:19] pita having to wait to file a mp [02:20] * StevenK puts up a branch with a DB patch that does "ALTER TABLE BranchRevision SET SCHEMA todrop;" for crimes against humanity [02:22] StevenK: That one'll surely fail to scan :) [02:22] Haha [02:23] Irony is lost on the branch scanner [02:25] StevenK: test_getPeopleWithoutAccess_bugs - i'd prefer to have a separate test for branches with a common _assert_getPeopleWithoutAccess method to make the pattern used for the other tests in the module [02:26] wallyworld_: I renamed it. So it isn't that :-P [02:26] StevenK: sure, but it's doing bugs and branches in the one tests and is different to how the other tests work [02:27] wallyworld_: This branch has already completly failed to scan, and you want me to push it again -- tempt fate, much? :-) [02:27] so i'd prefer a bug and branch "stub" which call the _assertXXXX bit [02:27] it's only the initiall push that is problematic [02:28] after that it scans fine each time i've found [02:28] creating a mp before the first scan borks for some reason [02:29] my request to change ensures that each test only does one thing [02:29] but uses a bit of common code [02:45] wallyworld_: Right, pushing that up now. [02:45] thank you [02:51] StevenK: r=me, thanks [02:51] wallyworld_: Yeah, I saw, thanks :-) [02:52] * StevenK tosses at ec2 and prepares to find some lunch [04:42] wgrant: I'm bashing my head against this branch. http://pastebin.ubuntu.com/1101291/ is the changes I've made since, following your suggestion of doing the filtering earlier [04:47] StevenK: Rather than finding the subscribers and then removing the subscribers that are unauthorized, perhaps just find the subscribers that are authorized [04:47] wgrant: That's what I'm attempting [04:48] + def forbidden_subscribers(self): [04:48] wgrant: That's for get_also_notified_subscribers() benefit [04:49] StevenK: So [04:49] I'd do something that works [04:50] And that also isn't horrible [04:50] If it works and isn't horrible, it's probably good to land [04:50] You said that about the last branch too [04:50] It didn't work :) [04:50] And look how that turned out :-P [04:50] If you can't work it out, I'll sort it out on Monday. === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [09:05] Do I need [testfix] to land a rollback branch at the moment? It's not related to the current buildbot failure, but PQM seems to be ignoring me. [09:12] Ah, there we go, finally got a mail back [09:13] So then the question is: is it legitimate to use [testfix] for a rollback that's not related to the buildbot failure, or is that Evil Bad and Wrong? === almaisan-away is now known as al-maisan [09:32] cjwatson: It's Evil and Wrong, but it's only particularly Bad if it's something that would otherwise need QA [09:32] cjwatson: It's still preferable to force the build first in this case. [09:32] Rather than using [testfix] [09:36] wgrant: Because this is a transient failure? [09:53] cjwatson: Right [09:55] OK, done === matsubara is now known as matsubara-afk === al-maisan is now known as almaisan-away [12:26] buildbot failing again, same celery failure [12:29] Hm [12:29] That's the third time today [12:29] I wonder if there was a relevant change [12:29] [r=benji][bug=1015667] run the Celery task RunMissingReady with [12:29] ignore_result=True [12:29] That's a bit sus [12:31] My thought exactly [12:31] Mother-in-law phoned or I'd have beat you to it :) [12:31] *beaten [12:32] In fact, that revision added the test which is now failing [12:32] Ah [12:32] It's just remarkably similar to the one that has been failing spuriously for months [12:33] Ah [12:33] Similar to the one that was failing spuriously for months until I disabled it a month ago [13:40] barry: wgrant found the origin of the bug you are getting. If it is true that there is a deactivated project that the bug affects, We want to try to delete the task (possibly by temporarily) reactivating it [13:41] sinzui: i don't understand what you're saying but i'm glad wgrant found the problem ;) [13:43] The comment is sent to Lp, lp select a bugtasks, then notices you don't have access to one of them, so sends a 404 that you see as an error [13:44] ah [13:47] Well I just looked in the qastaging db and there is nothing extra [13:47] The data is stale [13:47] * sinzui tries staging [13:47] and staging is also the same === bac changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: bac | Firefighting: - | Critical bugs: 4.0*10^2 === bac changed the topic of #launchpad-dev to: http://dev.launchpad.net/‹ | On call reviewer: bac | Firefighting: - | Critical bugs: 4.0*10^2 [13:55] barry I reactivated acton. I think you can report bugs [13:55] I think we need to decide if we want to delete the tasks or keep the project active [13:58] sinzui: I was able to reproduce it with my unprivileged account on that bug on qastaging [13:58] I see [15:05] mpt: you have way too much time on your hands at times :) [15:05] czajkowski, hey, it's Friday afternoon [15:05] am just laughing at your email [15:05] mpt: also where is my cookie! [15:06] I think you get cookies for fixing bugs. oh wait, that's a badge. [15:06] "Fixed an MPT bug" badge. [15:07] czajkowski, sorry, I just circumnavigated the office with the cookie jar but couldn't find you [15:08] mpt: bah! [15:08] mpt: next one you file is going invalid just for that ;p [15:08] nigelb, almost as good as the coveted [ MPT APPROVED ] badge [15:08] mpt: Ooh. I haven't gotten that one yet. [15:08] nobody is ever going to get that [15:14] not even mpt [15:15] Word. === salgado is now known as salgado-lunch [17:58] bug 1 [17:58] <_mup_> Bug #1: Microsoft has a majority market share you assigning that to yourself jml? [18:00] mgz: no, I'm just abusing the channel to find out the name of your bug bot [18:01] what, you mean you're to busy to fix that this weekend? === salgado-lunch is now known as salgado [18:14] mgz: yeah. you know. [18:15] mgz: furniture to assemble, household budgets to do, stacks of code reviews and one or two free software projects that I intend to crush. [23:08] Why is PQM still in testfix mode? http://lpbuildbot.canonical.com/waterfall shows the last devel build was successful. [23:08] Is it stuck because of db-devel? [23:10] cjwatson: Yes, PQM rejects everything when either builder is red, because a failure on any builder is a situation that is meant to be resolved as top priority. [23:10] Unfortunately, people tend to just ignore them instead, it seems :) [23:10] I forced it a few minutes ago [23:11] Failed for 16 hours, quite impressive