[00:54] wgrant: I would have expected http://pastebin.ubuntu.com/1097605/ to fail on the last assert. [01:12] StevenK: Hm, it may just happen to work atm. [01:12] But we still need the proper fix so that someone can always recover access and we can remove the default sub. [01:13] wgrant: I was going to add an null APG for USERDATA on private team creation [01:14] USERDATA on what? [01:14] We should have (pillar, information type) and (team,) APs, I suspect [01:15] I don't see a need for an information type for private team APs [01:16] wgrant: APs don't support teams [01:16] That I can see [01:17] StevenK: That's correct. [01:18] But there's no pillar involved [01:18] So they have to be made to support teams. [01:18] Currently APs have a key of (pillar, information_type), but they need to also support (team,) [01:19] Private junk branches are probably only allowed for private teams, and they get an AP of (team,) regardless of their information_type. [01:19] The AP is immutable and has a single APG: the team itself. === nigelb_ is now known as nigelb [02:14] * StevenK glares at wallyworld_, and picks lp.code.branchmergeproposal.nominate apart [02:15] StevenK: oh no, what have i done this time? [02:15] wallyworld_: Written lies which weren't lies when you wrote them. [02:20] oh, is that all :-) [02:22] wallyworld_: Actually, why is there a confirm_reviewer and a confirm_reviewer_nomination function? [02:22] StevenK: no idea, let me read the code [02:25] StevenK: one happens client side with known information when the mp page was loaded, the other as a result of mp submission [02:26] since the user could enter info that invalidates the initial check [02:29] StevenK: confirm_reviewer_nomination is a popup when submit is clicked [02:29] the other is a picker validation plugin [02:29] like is used for assigning a new person to a bug [02:29] it happens inside the picker when a reviewer is chosen === Pendulum_ is now known as Pendulum === gmb` is now known as gmb === matsubara-afk is now known as matsubara === frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: frankban* (rvba) | Firefighting: - | Critical bugs: 4.0*10^2 [09:00] cjwatson: do you need me to do some sort of annoucment for you ? [09:07] czajkowski: oh, right, let me find a TL to rubber-stamp^Wapprove my plan [09:07] czajkowski: unfortunately we can't import import nburrus/rgbdemo since it contains submodules [09:07] cjwatson: heading to stand up now [09:08] (also, good morning :) [09:12] Hm, I think I need to wait for the US to wake up [09:35] czajkowski: I was thinking of a post on the Launchpad blog something like this: http://paste.ubuntu.com/1097990/. It could use tightening up of language, moving the image to a more sensible/permanent place, and so on. [09:36] (And this is as yet unapproved so don't post it yet :-) ) [09:36] cjwatson: hehe ok, well I can review it later with mrevell on our 1-2-1 if you want [09:36] or do you need higher beings to ack it :) [09:38] bigjools was cautiously optimistic about the general plan but didn't feel plugged in enough to current Launchpad to ack the feature flag changes, so I'll need to grab a team lead for that. He suggested announcing the changes. Reviewing the text with mrevell would be good. [09:39] I went into a fair amount of detail as I thought this might be a little-known area that could benefit from a bit of light shone on it, but maybe I overdid it :) [09:40] cjwatson: I just want to highlight other people are helping getting launchpad updated in areas to encourage others to do so :) [09:40] cjwatson: jam is away this week so poke gary_poster or deryck [09:42] Right. Like I say, waiting for the US :) [09:43] ok :) === matsubara is now known as matsubara-afk [11:42] cjwatson, I'm here early because I very much need to do some more prep work for some interviews that start in 1:19. So, I've read your proposed blog post (sounds good) and I can spend another 3 or 4 minutes thinking about it. deryck will be around in a while. I won't be available again for five or six hours. [11:42] So, can I do anything else for you? [11:47] gary_poster: tell Jim I said hi, you've got him in a bit of awe :) [11:47] rick_h_, lol ok [11:53] gary_poster: I may have missed you. If not, the main thing I would like is approval to make a couple of feature flag changes: soyuz.copypackageppa.enabled on for everyone (AIUI this was disabled because of the lack of failed copy notifications, which is now fixed) and soyuz.derived_series.max_synchronous_syncs to 0 for launchpad-beta-testers so that we can see if async copies work for them [11:53] soyuz.derived_series.max_synchronous_syncs is currently set to something implausibly enormous in order to effectively disable asynchronous copies. [11:53] But I've been working on that area and they're working fine for me on dogfood. [11:54] So I think the next stage is to see if they work for other people. The ~libreoffice people ask me for manual copies roughly once a week at the moment so I expect they'll provide a test case soon, if nobody else does. [11:55] soyuz.copypackageppa.enabled will also permit the Archive.copyPackage API method to work when the target is a PPA. [11:58] Unrelatedly, what's the best Stormy SQLish way of saying "if there is a row matching condition A, return it; otherwise, if there is a row matching condition B, return it"? [11:59] Coalesce looks sort of right but I'm not sure. [12:01] cjwatson: What are you trying to do? [12:01] COALESCE isn't for whole rows, usually [12:02] I'm trying to do a version of the target => bug task search in Bug.setStatus that works for multiple bugs. [12:03] Currently it's doing several consecutive queries in Python. [12:03] Well, depending on the type of the target. [12:04] (I know this is only a tiny bit of the close_bugs_for_sourcepackagerelease problem, but I'm working myself up to it.) [12:04] Hmmm [12:05] So, say, for an IProductSeries target that method needs to find a product series task if there is one and otherwise fall back to a product task if there is one. [12:05] I'm not sure it's massively worth doing that, and it's going to be a bit of a challenge. [12:05] Not worth it because the ObjectModifiedEvent is going to cause O(tasks) write queries anyway [12:08] It's not really going to be practical to do all the task lookups in one query. I'd divide them up by type, doing the fallback in secondary queries as it does now [12:08] But batched [12:09] So look up tasks for all the targets. If there are productserieses left over, look up tasks for their products. If there are sourcepackages left over, look up tasks for their DSPs. [12:09] Why batched (within each lookup, I assume you mean)? I was kind of hoping it would be possible to get the query count low enough that it wouldn't be necessary [12:10] I guess the number of bugs is technically unbounded [12:11] Right [12:11] Though [12:11] The task lookup in setStatus right now should be one query [12:11] And only the first the first call on a bug [12:11] Subsequent calls should be 0 queries [12:12] Oh, because the first .target fetches all the columns? [12:12] Maybe I should just bulk-load the bugs then. [12:12] Ah, yeah, it uses target, so it resolves the whole thing. The .target call will be up to 2 queries for every task on the bug, but still only the first time. [12:13] However [12:13] That getBugTask thing is insane. [12:13] We have perfectly good ways to filter tasks by target [12:13] Without making hundreds of queries [12:14] Maybe I'm just being stupid but I couldn't find an obvious one that quite fit. [12:17] cjwatson: You can use a normal bug search. [12:17] cjwatson: See eg. Bug.userCanView [12:18] params = BugTaskSearchParams(bug=self.id) [12:18] params.setTarget(sometarget) [12:18] getUtility(IBugTaskSet).search(params).one() [12:18] or so [12:20] You'll probably want _noprejoins=True to avoid issuing more than one query [12:26] Bit of a problem with privacy there. [12:27] cjwatson: It'll default to not filter by privacy at all [12:27] Um [12:28] I lie [12:28] It defaults to public bugs only [12:28] Indeed [12:30] cjwatson: That's really the ideal way to do it, but the mandatory privacy filter is a bit annoying. [12:31] There's the evil circumvention of finding an admin user and passing that in ... [12:31] Yeah, but no. [12:31] Quite. [12:31] disable_privacy=True I guess [12:31] Well, privacy=False [12:32] Something like that. [12:32] filter_private=True maybe [12:32] Probably better to fix task search than use bug_target_to_key manually, anyway. [13:32] adeuring, https://plus.google.com/hangouts/_/84943eb8075e033904f027277d6b4e951afc2038?authuser=0&hl=en === jcsackett_ is now known as jcsackett [14:52] frankban: Could I have a review of https://code.launchpad.net/~cjwatson/launchpad/garbo-archivepermission-duplicates/+merge/115554 ? [14:52] sure cjwatson [14:52] I've checked that SQL fragment by hand on dogfood. [14:53] (Just as well since I'd never have got it right non-experimentally.) [15:43] frankban: review your way if you get a sec https://code.launchpad.net/~rharding/launchpad/reportbug/+merge/115562 === matsubara-afk is now known as matsubara [15:44] frankban: added a link to the first branch for some context [15:44] rick_h_: on it [15:45] ty much === salgado is now known as salgado-lunch === Ursinha` is now known as Ursinha === frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 4.0*10^2 === abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: abentley | Firefighting: - | Critical bugs: 4.0*10^2 [16:12] deryck: I'm the OCR. Could you please review https://code.launchpad.net/~abentley/launchpad/broken-xmlrpc-lookup/+merge/115582 ? [16:16] abentley, sure. [16:16] deryck: Thanks. [16:17] abentley, np [16:21] deryck: Would you mind having a look at my comments to gary_poster at http://irclogs.ubuntu.com/2012/07/18/%23launchpad-dev.html#t11:53 (and, for background, my conversation with bigjools at http://irclogs.ubuntu.com/2012/07/17/%23launchpad-dev.html#t23:31)? I'm looking for a TL to approve a couple of feature flag changes there. [16:24] cjwatson, ah, sure. Give me just a few minutes and I can look into all that. [16:33] rick_h_: hey, I can't say I understand every detail of it and I see this is fixing a critical bug so I don't want to hold you too long but I'm wondering about the lines 119-120 of the diff for the branch ~rharding/launchpad/reportbug. I'm wondering how that doesn't imply a change in the related test code...? [16:39] rvba: let me load it back up sec [16:39] rvba: no, the sharee test code didn't test the navigation html at all relying on the underlying code to test/do it [16:40] rvba: thought about adding a test, but wasn't sure if it was worth the LoC to test what's tested already. [16:41] rick_h_: all right, I guess that's ok if the code gets run by the tests somehow. I was just checking. Thanks for the explanation. [16:41] np, I thought the same thing tbh so understand the concern [16:42] Cool. [16:43] abentley, looks good, r=me [16:44] deryck: ty [16:45] np [16:46] cjwatson, in terms of the flags, you have my approval to change them. [17:03] deryck: Thanks. I'll get that onto LPS shortly. [17:06] cjwatson, np! [17:06] * deryck reboots, brb === deryck is now known as deryck[lunch] === salgado-lunch is now known as salgado [17:43] cjwatson: do you want it added to the blog then? [17:45] czajkowski: Yeah, was just waiting for the FF change to happen before asking you. http://paste.ubuntu.com/1098642/ is slightly updated text; is there somewhere more permanent you could put the image there? [17:45] czajkowski: I've also logged into wp-admin, and mrevell says you can post in my name once I've done that [17:46] he briefly explained this to me today [17:46] need to find you on the list [17:47] cjwatson: set to authour so lets see how this work [17:48] will fix the image up once it's in the blog [17:52] abentley: so care to be the 3rd person to review? https://code.launchpad.net/~rharding/launchpad/yuiv3/+merge/115592 [17:52] abentley: will not land until after veried everyone has the updated launchpad-deps package [17:54] czajkowski: Good to go [17:55] cjwatson: hmm I don't see it [17:56] will have a munch of dinner and investigate [17:56] czajkowski: See what? [17:56] cjwatson: ah thought you'd added it to the blog and in draft [17:56] Oh, do you mean you gave me permissions? [17:56] will sort it out after munchables [17:57] I misunderstood. I'll write up a draft. [18:02] rick_h_: okay [18:07] czajkowski: http://blog.launchpad.net/?p=3627&preview=true [18:10] rick_h_: 2083 is apparently the max URL length in ie8. [18:10] ah ok will update that. [18:12] cjwatson: lovely [18:12] posting to the places now [18:12] http://blog.launchpad.net/general/beta-test-asynchronous-ppa-package-copies [18:13] rick_h_: r=me [18:14] ty much abentley especially for the length catch. [18:14] czajkowski: Thanks. Belatedly fixed up the image a bit to not have bits of "demo" over the background [18:14] rick_h_71: np. [18:15] heh [18:15] looks good [18:15] thanks cjwatson [18:15] czajkowski: I'll do launchpad-users@ if you like [18:16] cjwatson: great [18:20] https://lists.launchpad.net/launchpad-users/msg06483.html [18:53] cjwatson: would it help if I stress tested copy-packages now? [18:55] micahg: Yes please [18:57] micahg: Though remember that if you copy source only then that's expensive in terms of build time [18:57] cjwatson: no, I have a bunch of Mozilla stuff I can copy to a PPA that's a no-op for users (12 sources + ~500+ binaries) [18:58] Sounds like a good plan [18:58] You'll be "charged" for it in terms of quota, of course [18:58] well, almost a no op, the PPA packages file will bloat a little, but not that much [18:58] I don't think there's any hardlinking on disk [18:59] Requested sync of 11 packages. [18:59] Please allow some time for these to be processed. [18:59] nice :) [18:59] ooh, and the PPA shows what's waiting [18:59] URL? [18:59] https://launchpad.net/~mozillateam/+archive/thunderbird-stable/+packages [19:00] ok, gotta run, will check later to see if everything worked [19:00] Either I was too slow or that's shown to the owner only, I forget [19:00] Would make some sense for it to be the latter [19:00] gone now [19:01] Oh, there's a bunch of Pending items there, which are probably yours [19:01] yeah, all looking good [19:01] (aside from not enforcing quota, but that was previous behavior as well) [19:02] Mm, possibly worth fixing [19:02] But otherwise sounds like flawless victory so far [20:15] hm, seems diffs linked to from +queue are getting the wrong host: 'lplibrarian-private-download.internal:8000' [20:16] yes [20:16] there is a bug [20:16] colin put up a patch yesterday IIRC [20:48] SpamapS,lifeless: it's fixed on devel - just needs me to do a bit of QA, then a deployment === cjwatson_ is now known as cjwatson [20:49] I guess I should see if it's possible to delete the busted diffs and have them regenerated, afterwards [20:49] excellent. :) [22:36] SpamapS: And passed QA, so hopefully deploying tomorrow. [22:42] cjwatson: I'll be doing QA after my stand up, and I'm tempted to put up a deployment afterwards. [22:58] I was considering setting status=PENDING for everything in SELECT COUNT(pd) FROM packagediff pd, sourcepackagerelease spr, archive a, libraryfilealias lfa WHERE pd.to_source = spr.id AND spr.upload_archive = a.id AND a.private IS FALSE AND pd.diff_content = lfa.id AND lfa.restricted IS TRUE; [22:58] Er, with syntax, but YKWIM [22:59] I think that would clear up the breakage. There are no such rows on dogfood right now, which is a good sign that at least it probably isn't overbroad [23:01] cjwatson: why noy just toggle the restricted flag for them ? [23:03] Wouldn't the actual diff need to be re-uploaded to the public librarian too? [23:03] That's certainly how it works when copying packages from private to public archives. [23:04] Seems easier to just get it to redo the diff - the bug hasn't been present for all that long so I expect it would be quick enough. [23:08] cjwatson: It's all a lie [23:08] cjwatson: The reupload is entirely unnecessary [23:08] I forgot we even still did that === wgrant_ is now known as wgrant [23:09] Seriously? And I spent actual effort understanding that. [23:09] There was perhaps an idea years ago that the two librarians would be separate [23:09] And possibly even extending it. [23:09] But that never eventuated [23:09] Hm? The majority of the code you touched was for working out the files [23:09] You still need to work out the files [23:09] You just need to toggle the flag rather than reuploading. [23:09] Yeah, I can't remember now. Plausible. [23:10] So OK, in that case flipping the flag is trivial enough. [23:31] Can I just ignore these ec2 test failures for AttributeError: type object 'InformationType' has no attribute 'EMBARGOEDSECURITY'? [23:31] huwshimi: Yes, wallyworld fixed those last night after two conflicting branches landed. [23:31] Ah