[00:00] StevenK: You have QA :) [00:02] sinzui, benji: logs/ isn't having much luck -- it's been added and then accidentally removed twice this week. How'd each of your removals happen, so we can make it stick this time? [00:04] % grep logs .bzrignore [00:04] logs/* [00:04] wgrant: ^ [00:04] logs/* [00:04] Not logs [00:04] Bleh [00:04] logs isn't ignored [00:04] wgrant: heh [00:04] wgrant: Not sure how to QA that branch [00:05] wgrant: I don't remember the circumstances of my removal (nor did I understand it at the time). [00:07] and I found the "!" pattern for .bzrignore that lets us ignore the contents of logs other than README.txt [00:07] benji: But logs/* is already ignored [00:08] StevenK: my understanding is that either order is important or negative patterns are higher priority [00:08] I may be mistaken, but if so, I don't see how the negative patterns accomplish much [01:15] wallyworld: When landing the end of a pipe, it might be a good idea to adjust the commit message to cover the whole thing, not just the last branch. [01:15] Your two megalandings have understated their actions by about a factor of 10 :) [01:15] it would be a very long message then [01:16] shouldn't all the commit messages along the way be aggregated? that would make sense to me [01:16] lp-land is not designed for megalandings like that. [01:16] So you have to do it manually. [02:34] wgrant: could you possibly take a look at https://code.launchpad.net/~wallyworld/launchpad/improved-bugremovesubscriptions-job/+merge/110447 [02:35] wallyworld: of course. [02:35] thanks [02:36] it would be good to see if the queries run ok on dogfood so that we can see if it can be turned on for prod [02:36] They won't run OK, but I can make them run OK. [02:36] Is this branch relatively final? [02:37] well, unless the queries need fixing [02:37] Yeah, I mean you don't like plan additional constraints. [02:37] i think everything is covered funcionality wise [02:37] i can add constraints if it will help [02:37] performance [02:38] but it's funcionally correct as is [02:39] Right. [02:39] Agreed. [02:39] i have no idea whether the current filtering on product/distro and info types as separate terms is better than an ap filter for example [02:41] The existing one is probably better atm. [02:41] But we can possibly gain a win from a GIN index on BTF.access_policies and filtering on that. [02:41] I'll find out after lunch.; [02:41] ok, hopefully we can get this turned on early next week i guess [02:42] wallyworld: Have you played around with this in full locally? [02:42] Last time I tried I filed 11 bugs. [02:42] Looks like about half, and all the major ones, have been fixed. [02:42] i 've done some testing, mainly tried to get unit test coverage [02:42] The major omissions are triggering the jobs on information_type and target changes. [02:42] Oh, also creating AAGs when making a bug private. We haven't decided on rules for that. [02:42] ? i thought that was covered [02:43] the jobs are triggered on info type and target changes and there are tests for that [02:43] Oh, are they. That's handy. [02:43] Forgot that detail, apparently. [02:43] that bit was never missing, unless i'm totally wrong [02:44] Yeah, you're right, I think. [02:44] so, creating AAG for bug -> private should be the last bit [02:44] Yeah [02:44] Bug #1009364 [02:44] <_mup_> Bug #1009364: AccessArtifactGrants not created on bug privacy transitions without triggers < https://launchpad.net/bugs/1009364 > [02:44] Is what I was thinking of. [02:44] yep [02:44] wallyworld: Bug #1009363 also looks fixed now, since that job is gone. [02:44] <_mup_> Bug #1009363: RemoveGranteeSubscriptionsJob._unsubscribe_pillar_artifacts has a slow reimplementation of bugtasksearch

< https://launchpad.net/bugs/1009363 > [02:45] yes [02:45] i'll link that bug to this branch [02:45] Although it also probably applies to the RemoveBugSubscriptions, it's not quite as bad or gratuitous there. [02:45] not any more [02:45] that was fixed a couple of branches ago [02:45] Do you have thoughts on bug #1009356? Pretty minor, not sure if it's easy. [02:45] <_mup_> Bug #1009356: Sharing a subset of information types generates a subscription removal job for the others < https://launchpad.net/bugs/1009356 > [02:46] oh, it's harmless but unnecessary [02:46] Sure. [02:46] Might not be worth avoiding. [02:46] But if it's a one-liner, might as well. [02:46] i can look at it, [02:46] To avoid all the extra jobs. [02:47] r=me, anyway. [02:47] Thanks for fixing that. [02:47] so the AAG thing, why do we want to create AAG for subscribers to the formerly public bug? [02:48] thans for the review [02:49] if the bug goes from public to private, then people who are not allowed to see it should have their subscriptions removed, those who can see it will have APG or AAG already, no? [02:51] wallyworld: When it becomes private nobody will have an AAG. [02:51] wallyworld: It's not clear who should have one. [02:52] But in the current implementation nobody will.l [02:52] Including the person who is making it private. [02:52] those who have an APG will be ok though [02:52] So eg. a reporter can't flip their bug to private if they misfile it as public. [02:53] so for now can we just create one for the key roles - reporter and person doing the flipping perhaps [02:55] Reporter isn't a key role. [02:55] But probably, yeah. [02:55] We almost need to make it explicit. [02:55] Which is why I was thinking we should just create one for all the subscribers. [02:55] as a reporter i think i should be able to see the bug [02:56] i think we should start narrow [02:56] I forget what we do now. [02:56] You changed the behaviour last year, but I don't remember if it stuck. [02:56] i think it was bug supervisor and all direct subscribers, but am unsure [02:57] what do the triggers do? [02:58] wallyworld: The triggers do subscription == visibility [02:58] So there's a 1-1 mapping. [02:59] So there's a grant for anyone that the app leaves a subscription for. [02:59] do we know what our stakeholders expect for the new world order? [03:00] it seems dangerous to just convert all existing subscriptions [03:00] The stakeholders are likely to care much; they all want private projects, so they don't care about public->private [03:00] wallyworld: It can't leak the bug any more than it has already leaked. [03:01] Because it was previously public. [03:01] but new conversations will be invisible [03:01] Sure. [03:01] And before you have the new conversation you should ensure that only people who should see the bug can see the bug. [03:02] so in that case we should just convert all existing direct subscriptions [03:02] I think that's correct for now. [03:02] It's certainly correct for the underlying layer. [03:02] I'm not sure what the application does currently. [03:02] It may already remove some of the subscriptions. [03:02] it may do, can't recall, i'll have a look [03:52] wallyworld: :( [03:52] Looks like I won't be filing 10 bugs about the jobs today. [03:52] It seems correct, apart from needing some query optimisation. [03:53] some of those 10 were questionable [03:53] what query optimisation is needed? [03:54] oh shit, gotta duck out to drop off something before the office closes, biab [04:15] wallyworld: A quick rewording from an IN to a JOIN gets it down to 10s for identifying subscriptions affected by removing a hypothetical ~ubuntu-bugcontrol grant to Ubuntu. [04:15] (that's some 399500 subscriptions) [04:15] So that's quite acceptable. [04:15] Given that it's about the worst conceivable case. [04:21] wgrant: http://pastebin.ubuntu.com/1041847/ [04:23] wgrant: thats not-inline with the webapp request though ? [04:24] lifeless: No, this is a job. [04:25] StevenK: It'd be nice to test the triggers, rather than just that the underlying function works. [04:25] StevenK: This just tests the information_type UPDATE trigger. [04:26] StevenK: You can probably test the AAG/APA triggers in about 3 lines. [04:26] No need for INSERT/DELETE really. Just a quick test to check that INSERTing each updates the columns. [04:27] Although APA is a bit complicated, since we only expect one. So you'll need to UPDATE for the APA test. [04:29] * StevenK stabs rhythmbox, and then twists the knife. [04:29] 2854 steven 20 0 9895m 5.3g 12m S 1 68.6 14:20.41 rhythmbox [04:29] 5.3G RSS? [04:30] And 10G virt? [04:30] So it's swapping? [04:30] 8G of RAM, so it was swapping heavily [04:30] Yeah [04:30] Thank god for amd64. [04:30] Or it wouldn't be able to get all the RAM it needs :P [04:32] So Quod Libet will randomly stop playing after a song finishes, and it looks like rhythmbox leaks like a sieve. [04:33] wgrant: Three lines? Really? [04:33] makeBranch [04:33] assertAccess [04:33] makeAccessArtifactGrant [04:34] assertAccess [04:34] 4 lines [04:34] So a USERDATA branch, or PUBLIC? [04:44] StevenK: It has to be private. [04:57] wgrant: http://pastebin.ubuntu.com/1041889/ [05:08] StevenK: makeAccessArtifact should fail, since the branch should already have one. [05:08] Does it not? [05:09] Hm, not sure if I ran the tests before pasting. [05:09] wgrant: It does not fail. [05:10] That is a matter of some concern. [05:11] StevenK: See Branch.transitionToInformationType's _reconcileAccess call [05:11] That should be creating the AA [05:19] wgrant: Hm, I see .... [05:26] wgrant: How can I check if it has an AA? [05:27] StevenK: I'd check postgres logs to see if you can see the INSERT [05:28] But if you want to programatically check, getUtility(IAccessArtifactSource).find([branch]) [05:31] INSERT INTO AccessArtifact (bug, branch) VALUES (NULL, 77) RETURNING AccessArtifact.id [05:31] Not sure if that's my makeAA call [05:33] artifacts = getUtility(IAccessArtifactSource).ensure([concrete]) [05:33] That sounds like it will just return one if it exists ... [05:34] StevenK: ensure creates any that are missing. [05:43] wgrant: Hmmm, which does return one. That is most perplexing [05:44] "accessartifact__branch__key" UNIQUE, btree (branch) WHERE branch IS NOT NULL [05:44] So that's not the problem. [05:45] wgrant: I have a 261K psql log you can grep through if you wish. [05:45] Changing it to artifact = getUtility(IAccessArtifactSource).find([branch])[0] [05:45] Also has the test pass [05:46] Oh heh [05:46] makeAccessArtifact calls ensure [05:46] That explains it. [05:47] That was what I tried to say earlier, and failed. [05:47] Oh [05:47] I misunderstood. [05:47] I thought you meant that was part of _reconcileAccess [05:48] wgrant: With that cleared up, are you happy with the tests? [05:48] If they pass, indeed. [05:48] All two of them [05:48] Then it sounds reasonable. [05:48] Ran 2 tests with 0 failures and 0 errors in 0.539 seconds. [05:56] wgrant: Thanks for all your help with this massive thing. [05:57] stub: https://code.launchpad.net/~stevenk/launchpad/db-branch-new-access-policy/+merge/110464 would love a DB review. [05:57] Hah, not massive. [05:58] wgrant: It's felt massive at times. [05:58] It's one of the largest DB patches I've done. [05:58] I still keep getting 'Updating diff' on mps that already seem to have perfectly good diffs [05:58] stub: I think it can take a while to go away. [06:01] I thought I nuked comments.sql? [06:02] We don't apply it any more. [06:02] But it continues to exist. [06:02] wallyworld: You have eight cards in QA-Landing, can you have a look? [06:03] stub: comments.sql is still applied by make schema [06:03] It isn't on production anymore. [06:03] Right, that's what I meant. [06:04] Right. Thought I tossed it from dev too along with trusted.sql [06:04] I think trusted.sql might still be applied, it's just empty. [06:04] Even on prod [06:04] Yeah [06:04] I'll leave nuking comments.sql for someone who needs the LOC :) [06:06] % loc-contributions 'Ian Booth' [06:06] 12535 [06:07] That's what you get for writing code. [06:08] I've been writing code, and I'm at 473 [06:08] This DB branch will probably push me to 700 [06:08] wgrant: You're only at -28 [06:10] Huh [06:10] Oh [06:10] I'll get the blame for all the DB patches. [06:10] Since I do the merge. [06:11] That's a bit mean. [06:13] StevenK: they are all in progress [06:14] but will be moved after the next bb run hopefully [06:15] wallyworld: We've had three deployments in the past two days, I'd hope some of them are done. :-( [06:15] Most of them were in the pipe that I reviewed yesterday [06:15] StevenK: sure, but my pipe only just got through ec2 [06:15] that one is landing now [06:15] i had to fix a test failure this morning [06:17] Need covering indices :( [06:26] stub: How is the review? [06:26] going [06:31] StevenK: It looks fine. I haven't had time to fully grok it for bugs, but there are tests for that. [06:31] StevenK: You want to land this today? [06:31] stub: I think the FDT queue is empty, so this could hopefully deploy Monday night [06:32] Ok. wgrant has already gone over the logic? [06:32] I wrote it. [06:34] ok. r=stub. I'll go over it again later but it seems fine. [06:34] Well, I gave a draft to StevenK and he polished it up. It seems good to me. === jtv1 is now known as jtv [06:35] yer, I just need to grok the logic more to see if I can come up with any missed edge cases. What is there seems fine. [06:35] Most of the non-trivial logic is just generalised from the existing bug functions. [07:24] wallyworld: If you're still around, you're probably well-placed to consider https://code.launchpad.net/~wgrant/launchpad/improved-bugremovesubscriptions-job/+merge/110480 [07:24] wgrant: looking [07:25] Feel free to object to the repr changes. [07:25] But I think we need something more detailed than we have now. [07:25] wgrant: i did the join in my current branch, i'll back it out [07:26] the repr changes are fine, i initially just wanted to get the jobs working. there were issues with repr not being correct for derived classes so i left them generic initially [07:26] Yep [07:26] speaking of security [07:26] http://blog.xen.org/index.php/2012/06/13/the-intel-sysret-privilege-escalation/ [07:26] should give us chills [07:26] Yeah, that was a pretty good one. [07:27] AMD invented that instruction [07:27] So I'm pretty sure Intel's implementation is just buggy [07:29] differently valid ? [07:29] wgrant: do we need the distinct=true [07:29] wallyworld: Yes, since BTF can have multiple rows per bug. [07:29] lifeless: Well [07:29] lifeless: Intel's definition doesn't make much sense. [07:29] lifeless: And EM64T intended to be compatible with AMD64. [07:32] Oh [07:32] That article actually has a section on that sort of thing [07:32] wgrant: r=me, thanks. i'll have the aag one finished after soccer later tonight, i'll get yoo to review [07:33] wallyworld: Thanks. [07:33] And will do. [07:35] did you see http://io9.com/5918453/cooked-squid-inseminates-womans-tongue-cheek-and-gums ? [07:36] Heh [07:37] weird shit [07:41] good morning === Gwaihir_ is now known as Gwaihir === Gwaihir is now known as Guest34734 === almaisan-away is now known as al-maisan === Gwaihir_ is now known as Gwaihir === adeuring changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | Welcome our new intern: ivory | On call reviewer: adeuring | Firefighting: - | Critical bugs: 3.47*10^2 [08:53] lifeless: the-intel-sysret-privilege-escalation> I suspect you will enjoy the discussion about the disclosure process, when that comes out [08:55] How do you file a bug about a instruction set. === al-maisan is now known as almaisan-away [09:25] Why does contents-generation generate its own dists/ rather than copying the most recent published version, anyway? I get why it has a separate dists/, but I don't really see why it has to go to the effort of generating its own. [09:28] Oh, maybe it's just hard to get apt-ftparchive not to do so. [09:29] Because I hate apt-ftparchive. [09:30] But yeah, it's probably difficult to tell it otherwise. [09:31] Or was in 2006. [09:32] It takes it 100+ minutes to generate all the Packages and Sources again, so avoiding that would be a nice improvement. [09:33] Then Contents takes 90 minutes. [09:33] * cjwatson files a bug. [09:33] Oh [09:33] It doesn't preserve? [09:34] Not so you'd notice. [09:34] Heh [09:35] I love cjwatson bugs, as I know they are never going to be invalid or dupes (in most cases) [09:35] so I can traige them easily [09:37] heh [09:37] jml: less so yours :s [09:37] that's cos I live on the edge, man [09:38] my stylez are too intense for the mainstream [09:38] yes thats the reason :) [09:38] see what I did there? I put a 'z' in stylez. Backatcha! [09:38] lol [09:56] ivory: you're really making progress [09:58] czajkowski: i feel like i learned more useful things in this week than in 12 years of school :) [09:59] ivory: excellent! [10:07] ivory: :D [10:08] open source hacking ftw [10:11] I uploaded a package to a PPA that I accidentally made private. I then create a public PPA and uploaded that same package to it. === matsubara is now known as matsubara-lunch [10:12] However, https://launchpad.net/~jml/+archive/consumer-apps-tools has no record of any build or upload, and when I try to dput again I get told that Package has already been uploaded to ppa on ppa.launchpad.net [10:12] Nothing more to do for create-usc-ppa_0.1_source.changes [10:12] what's going on? [10:13] jml: dput -f [10:13] wgrant: why does LP think it's already uploaded? [10:13] jml: dput (for not very good reasons) creates a .upload file locally when it completes an upload. [10:13] LP doesn't. [10:13] That's dput [10:13] ahh. [10:14] I have a theory that it was a feature added just to confuse people. [10:14] my brain, she grows! [10:14] wgrant: you don't say! [10:18] wgrant: is there another explanation for those files? [10:19] Hah [10:28] I'm trying to add a simple 'does the script load' sort of smoketest for the fix-translations script (I'm also adding it to the launchpad scripts/ folder). Can anyone point me to where that test should live? [10:29] I guess I see some doc tests for 'copy-translations-from-parent' script under: lib/lp/translations/doc/... [10:30] or maybe that isn't a doctest [10:30] no, they are [10:32] jam: lib/lp/services/scripts/tests/test_all_scripts.py may be of interest [10:33] wgrant: thanks, that looks like the smoke test I wante [10:33] wanted [10:52] wgrant: db-devel r11683 [10:52] nyah ah ah ah ah! my patch got into this run of buildbot [10:52] now I'll get results before the end of my working day [10:52] jml: Lies. [10:52] StevenK: Excellent. [10:52] Monday it is. [10:53] It has missed buildbot by about 15 minutes, butmeh. [10:53] It has nearly three days. [10:53] Yes, hence 'meh' :-) === matsubara-lunch is now known as matsubara [11:09] oh right. [11:09] I can't seem to use the API against launchpad.dev [11:09] I get an error about SSL. [11:09] Yeah, cert verification will break that. [11:10] httplib2.SSLHandshakeError: [Errno 1] _ssl.c:504: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed [11:10] wgrant: is there a work around? [11:10] I either hack launchpadlib to not verify the cert, or generate a new cert for launchpad.dev and tell it to trust that. [11:10] I often end up hacking httplib2. [11:10] (search for disable_ssl and change False defaults to True) [11:10] I wish there were an environment variable override. [11:11] dogfood has the same problem. [11:11] wgrant, cjwatson: thanks. [11:13] jml: In lazr.restfulclient._browser.RestfulHttp.__init__, add disable_ssl_certificate_validation=True to the super call [11:14] wgrant: even better, thanks. [11:17] There are three sites you need to change, IME. [11:17] I always forget the full list. [11:17] Which is why I've started editing httplib2 instead. [11:17] Yeah [11:17] Trial and error works for me... [11:17] Because not all the call sites are in the same file. [11:17] Yep [11:23] jml: That's cheating. [11:24] wgrant: it's not cheating if you win. [11:24] wgrant: anyway, I haven't tested at all, or written automated tests, and it needs a comment and I can't find those other call sites you mentioned. [11:25] I don't remember what they look like. [11:25] It's just a matter of killing things until you run out of tracebacks. [11:27] yeah. I'll poke at that. [11:27] although I really need to move on from LP hacking to my next project. [11:28] * jml has lunch instead [11:31] wgrant: any idea what back end project this belong so [11:31] 12:30 < popey> if you search in the video lens, it goes off to that website to get results [11:31] 12:30 < popey> http://videosearch.ubuntu.com/v0/search/ [11:31] 12:30 < popey> see^^ [11:31] 12:30 < popey> and AIUI that backend is in lp somewhere, but I dunno what it's called [11:34] it's okay I'll ask u1 people [11:36] popey: I think that's candiru [11:36] nice timing! [11:36] But don't quote me on that. [11:36] 12:36:22 < popey> found it! [11:36] 12:36:23 < popey> https://launchpad.net/candiru [11:36] :D [11:36] Heh [11:36] thank you. [11:36] popey: I di say the only person that might know would be wgrant [11:37] *did [11:37] hehe [11:59] bac: I just noticed your message. So the tests try to capture sys.stdout but now they should capture sys.__stdout__, right? [11:59] How the hell did wgrant reach -18281 :) [12:01] Hm? [12:02] That sounds off by a factor of 10 [12:02] or more [12:02] Maybe in my all-time commit history. [12:02] But not since the policy was introduced... [12:02] I mean.... you're higher than StevenK by an order of magnitude [12:02] Oh [12:03] That was indeed from before the policy. [12:03] That explains it. [12:20] wgrant: oh yeah, two things [12:21] removing the debbugs db from the tree [12:21] Yay [12:21] Kill [12:21] But how? [12:21] also, rolling back other people's commits [12:21] Oh, did I delete it already? [12:21] That's right, I deleted a duplicate copy. [12:21] as in, those are two things you did that inflated your pre-policy score [12:21] the debbugs db most significantly [12:21] There's still one copy lurking there. [12:21] right. === olli_ is now known as olli [14:04] abentley, adeuring, ivory -- let's try this: https://plus.google.com/hangouts/_/62374aa6d5f5280d63ca32c5288e194fd3ed8ba5?authuser=0&hl=en === bac changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | Welcome our new intern: ivory | On call reviewer: adeuring, bac | Firefighting: - | Critical bugs: 3.47*10^2 === Gwaihir is now known as Guest56170 === matsubara is now known as matsubara-afk === salgado is now known as salgado-lunch [17:29] engineering trying to look at a failed build log for a package with tildes in the version must manually encode the tilde and this method apparently only works in Firefox as Chrome does not allow you to do this? For packages with tildes is there a way we can provide an alternative link with the filename hashed? === salgado-lunch is now known as salgado [18:47] I think I have finally found a way to make sprite links that work properly in all browsers [18:57] I see my copy of " YUI 3 Cookbook" has finally shipped. [19:00] sinzui: just downloaded that to the kindle last night myself [19:01] rick_h, It was not available two weeks ago when I checked. I don't want to dead tree [19:02] sinzui: ah, yea just saw it when davglass posted it to twitter that the book arrived [19:02] bad thing about the kindle setup is you can't 'wishlist' it like a paper version so have to wait [19:03] pre-order that is [19:04] :/ [19:04]