[00:01] StevenK: Well, it's completely valid. [00:01] StevenK: You're just invalidating the assumptions it's based on. [00:02] StevenK: Is that one of the tests that I said you should keep? [00:02] StevenK: The key is that not all structsubs will produce notifications. [00:02] The one tested in that test does, because it uses the owner for convenience. [00:02] So change the test to not subscribe the owner, and it will hopefully pass. [00:03] lp.bugs.model.tests.test_bug.TestBugPrivateAndSecurityRelatedUpdatesPrivateProject.test_transition_to_private_grants_subscribers_access [00:03] What a test name. [00:04] wgrant: So if I change the test to structually subscribe a different person, then it is pretty much lp.bugs.tests.test_bug_notification_recipients.TestBugNotificationRecipients.test_private_bug_with_structural_subscriber [00:05] "This seems like a reasonable integration test to retain. You've added a test that sharing => notification in test_private_bug_with_structural_subscriber_with_access, but unless I've missed one this is the only one that tests !sharing => !notification." [00:05] I missed one :) [00:06] Right [00:06] wgrant: That doesn't happen often. :-) [00:06] Hah [00:06] You should always doubt me. [00:07] Unless I'm right. [00:08] wgrant: I've addressed all of your comments, aside from the two related to (368-369, 392-396) [00:09] Those two can wait until after breakfast. [00:09] StevenK: What breaks when you filter direct subscribers? [00:09] That bit is not negotiable. [00:09] 392-396 might be [00:10] wgrant: No fair engaging me with questions when my stomach is threatning to break out and find breakfast on its own. [00:10] StevenK: that sounds beneficial. [00:10] It means you can keep working on this branch while your stomach eats. [00:35] wgrant: Hah [00:35] wgrant: So I think your comment of "The function didn't previously return nothing for private bugs, ..." is wrong, since I think it was never actually called for private bugs. [00:52] StevenK: It may not have been. [00:52] StevenK: But you'll need to check other callsites. [00:53] I'm about to filter direct subscriptions so I can show you the breakage. [00:53] Great. [00:57] wgrant: http://pastebin.ubuntu.com/1120572/ is the crux of the breakage [00:58] StevenK: Why does that happen? [00:59] wgrant: Like I said on the call, I didn't investigate. [00:59] I figured out it works if I don't filter direct subscriptions and left it at that. [01:00] Right, you should figure that out. It's probably because it adds grants for direct_subscribers [01:01] Depending on what else calls direct_subscribers, you may not want to filter direct_subscribers itself [01:01] But a wrapper [01:01] wgrant: direct_subscribers is a wrapper around direct_subscriptions [01:02] Sure [01:02] But it's a wrapper for a different purpose [01:02] Hm, nothing seems to call it directly [01:03] # Grant the subscriber access if they can't see the bug. [01:03] subscribers = self.getDirectSubscribers() [01:03] That might be relevant [01:03] Yes, I was about to dig into callsites of getDirectSubscribers() [01:05] Oh, is that working around a bug in the sharing service? [01:05] Probably not. Why? [01:06] I was guessing self.getDirectSubscribers() == [] [01:06] Looks like I'm wrong [01:07] The sharing service doesn't know about subscriptions. That's not its job. [01:07] Now [01:07] Filtering Bug.direct_subscribers directly is probably wrong [01:07] Since people are still subscribed [01:07] They just can't see it. [01:09] wgrant: Oh? Shall I substract it from also_notified_subscribers then? [01:11] StevenK: They need to be notified if they have access [01:11] Like also_notified_subscribers [01:11] also_notified_subscribers is only used for notification purposes [01:12] It is only meaningful for notification purposes. [01:12] So it is sensible to filter that there. [01:12] But direct_subscribers isn't just used for notification. [01:12] Right, so you *do* want me to filter it in also_notified_subscribers [01:12] Not subtract it from :) [01:13] Just trying to work out how to filter ... [01:13] StevenK: In fact [01:13] Hm [01:13] self.direct_subscribers_at_all_levels is not the place, since that backs directly onto direct_subscriptions [01:14] so [01:14] direct_subscribers is just used for exclusion, it seems [01:14] I misread. [01:14] The real thing you need to filter is the getDirectSubscribers call in getBugNotificationRecipients [01:16] Hmmm [01:16] Which is in the guts of IBug itself, the rest of my playing has been in BugSubscriptionInfo [01:17] wgrant: So not getDirectSubscribers() itself? Since we already figured out that fiddling with recipients after the fact is Bad. [01:22] In related news, methods that mutate their arguments are bad. [01:23] Who woulda thunk it [01:24] StevenK: transitionToInformationType and a couple of other places use getDirectSubscribers for non-notification purposes. [01:26] Right, but trying to remove things from BugNotificationRecipients afterwards is what led to a rollback and this branch in the first place. [01:28] Certainly. [01:28] I didn't suggest filtering afterwards :) [01:28] I just implied that you can't do it directly and unconditionally in getDirectSubscribers [01:29] wgrant: Modulo some clean up, http://pastebin.ubuntu.com/1120614/ [01:31] StevenK: Right, that's probably reasonably sensible. [01:33] Now to make it work [01:34] * StevenK tries to remember how set operations work [01:36] wgrant: I can't just set direct_subscribers, since it expects to be a BugSubscriptionSet, I'm trying to remember the set operation for "Remove everything in set A that isn't in set B" [01:37] sinzui: i am thinking that it would be better to add a remove icon next to the bug dupe link in the portlet (like is done for removing subscribers on the same page) rather than add a new link to the picker. that way the portlets on the page behave consistently [01:37] wallyworld_: It's a bit different, though [01:37] Which is intersection(), I thinjk [01:37] wallyworld_: Since with the dupe thing you can only have one, and you can change it. [01:37] wallyworld_: It's more similar to assignee that subscriber. [01:38] s/that/than/ === nigelb is now known as nigel-cloud [01:38] which i think is silly also to have to open a picker to remove [01:38] there should be a remove icon next to the pencil icon for assignees etc [01:39] StevenK: >>> s = {1, 2, 3} [01:39] >>> s.difference_update({1, 3}) [01:39] >>> s [01:39] set([2]) [01:39] wallyworld_: Maybe, yeah [01:39] wallyworld_: But we probably want to be consistent. [01:39] wgrant: intersection_update(), since I want the intersection of the two sets. [01:39] yeah, i can't decide [01:40] StevenK: Oh, bah, missed "isn't" [01:40] But BugSubscriptionSet doesn't implement that. [01:40] You might have to get to it before it objectifies it. [01:40] Or alter getDirectSubscribers' other callsites to not call getDirectSubscribers [01:41] No, I need to recreate it, BugSubscriptionSet is a frozenset [01:41] ... somehow [01:41] Due to @freeze(BugSubscriptionSet), porbably. [01:42] The following table lists operations available for set that do not apply to immutable instances of frozenset: [01:42] Which intersection_update() is in [01:43] Sure [01:43] A frozenset is frozen [01:43] So updating it doesn't make an awfully large amount of sense. [01:43] Yes [01:44] direct_subscribers = BugSubscriberSet( [01:44] direct_subscribers.intersection(filtered_subscribers)) [01:48] wallyworld_: In r15569 you changed bug filing to not respect extra_data.private if the user is a bug supervisor. Do you recall why? [01:49] (it probably means that apport-filed bugs for ~ubuntu-bugcontrol end up public unless someone's watching carefully) [01:49] hmmm. not of the top of my head. i'll see if i can remember [01:50] HAHAHA [01:50] * StevenK notices a typo in accesspolicy [01:50] StevenK: Where? [01:51] def revokeByArtifact(cls, artifacts, grantees=None): [01:51] - """See `IAccessPolicyGrantSource`.""" [01:51] + """See `IAccessArtifactGrantSource`.""" [01:51] cls.findByArtifact(artifacts, grantees).remove() [01:52] Copy-paste errors in docstrings of boilerplate methods. How novel :) [01:57] wgrant: i can [01:57] can't recall whyt thaT CHANGE WAS MADE [01:57] arg, caplock fail [01:58] wallyworld_: Yeah, I can't see a good reason. I'm replacing that code, so I'll ignore it :) [01:58] Thanks. [01:59] ok, thanks [01:59] too bad we didn't have tests that failed [02:02] wgrant: Diff updated, can you cast your eye over it again? === nigelbabu is now known as nigelb [02:34] StevenK: Sec [02:34] wallyworld_: Why's +filebug's information type widget part of bugtarget-filebug-guidelines.pt, rather than with the rest of the form? [02:35] I don't really understand why that view is separate at all. I wonder if it might be because of the way ProjectGroup:+filebug used to work [02:35] Which means it can probably be merged. [02:35] from memory that's how it was originally all set up [02:35] that's where the old privacy/security checkboxes were [02:35] Huh [02:36] Indeed. [02:36] it's all a a bit of a mess [02:36] Ah, of course [02:36] Because the security_related checkbox had the name of the security contact in it [02:36] So it was project-dependent. [02:36] yes, makes sense [02:36] But ProjectGroup:+index just redirects now, so that can all be merged. [02:36] * wgrant merges. === beuno_ is now known as beuno [03:16] wgrant: How about now? [03:16] Since your 'sec' has turned out to be a description of how long it will take you to get distracted, not how long it will take you to look at my MP. [03:17] lol [03:45] StevenK: r=me [03:47] is there a way to have the status of a bug in launchpad set to fix released automatically when a package is automatically built from recipe? [03:49] cr3: No. You'd have to write a launchpadlib script to do that. [03:49] Recipes are normally used for daily builds, which aren't usually "releases" [03:50] wgrant: that makes sense actually, thanks! [03:53] wgrant: I guess that branch doesn't fix bug 901548, but lays the groundwork? [03:53] <_mup_> Bug #901548: launchpad does not send emails to the assignee of private bugs < https://launchpad.net/bugs/901548 > [03:53] StevenK: I think it probably fixes it implicitly. [03:54] I'm pretty sure I tested that case, in fact. [03:54] But that was like 4 days ago [03:54] Then I'll link the bug and branch, thanks. [03:54] Like [03:54] Why wouldn't it fix it? [03:55] It seems like it should [03:55] Since the assignee is in also_notified_subscribers [03:55] That's a point. [03:58] stub: Hai! https://code.launchpad.net/~stevenk/launchpad/db-bugsubscriptionfilter-itype/+merge/117003 would love an review. [04:01] StevenK: What are the different information types again? [04:01] huey duey and louie [04:01] stub: has mthaddon been in touch w.r.t. django session cleaning mark 2 ? [04:01] stub: PUBLIC, PUBLICSECURITY, PRIVATESECURITY, USERDATA and PROPRIETARY [04:02] lifeless: Not yet [04:02] stub: The idea being that someone can structurally subscribe to all PRIVATESECURITY bugs. [04:03] stub: ok, so - we're triggering mass locks in vacuum, theory is its scanning for pages to fill into but the table is so big... it takes ages *and* holds locks while it does the scan. [04:03] stub: so the cleanups are on hold; I've suggested we do a bait and switch to a new table [04:04] with a background clone of live sessions + a indexed copy of new sessions only during a FDT-like window. [04:05] lifeless: That looks like oops-tools success. [04:05] StevenK: Yeah, I was thinking humans would be interested in 'all', and 'security'. [04:05] stub: It is following the currently established pattern, see BugSubscriptionFilterStatus and BugSubscriptionFilterImportance [04:05] StevenK: Yeah, model is fine. I'll leave it up with you guys to design the UI. [04:05] * StevenK digs for a bug [04:05] StevenK: My initial reaction is we have a confusing UI if it allows someone to subscribe to just publicsecurity bugs, or just userdata bugs. [04:05] StevenK: But I'm not reviewing that :) [04:06] lifeless: How did you confirm vacuum is taking locks? [04:07] stub: lock dependency graph shows it holding locks, strace shows it reading lots of data. [04:07] lifeless: what sort of locks? [04:08] I don't recall, I think they were row level (but rows that sessions were trying to use) [04:09] Right, autovacuum is supposed to not affect anything and release locks and back off if other stuff needs them. [04:09] it backs off at the deadlock detection interval [04:09] it definitely takes locks out :) [04:09] These are 8.4 though... [04:09] wgrant: Hmmm, is there a bug for filter by InformationType? [04:10] wgrant: I thought there was one, but I'm having trouble finding it [04:10] Ah, found it [04:12] stub: Can haz stamp on the MP? [04:13] lifeless: Some vague hints that it might be our use of the CURSOR... [04:14] lifeless: Why repeated oops tools mails? [04:15] StevenK: Do you really want that 'id' column? [04:15] stub: It's a many-to-many relationship, I think it's needed [04:15] StevenK: Testing the new report-specific addresses [04:15] StevenK: So we don't get U1 [04:16] StevenK, stub: It's not necessary, but it's probably best to match the others [04:16] (which have the ID, for reasons that are not clear) [04:16] wgrant: Ah, testing on production. WCPGW. [04:16] StevenK: Oh. Why isn't the (filter, information_type) unique? [04:19] stub: Because I was making it match Status and Importance, but that's not the best answer. [04:19] lifeless: yes, the cursor we use to maintain the list of rows to remove can pin blocks. " If, for example, someone leaves a cursor open, the data block to which the cursor refers is busy (the technical term is "pinned") and can't be vacuumed until the cursor is closed or moved to a different block" [04:20] StevenK: At the moment, you can have two identical rows. That means your queries are going to need DISTINCTS all over the place to remove the redundant rows when you join with that table. [04:22] StevenK: There is no reason for (filter, information_type) to not be unique, since there is no other actual information in the table (id doesn't count as information) [04:22] stub: So, maybe we fix Status and Importance in the same patch [04:22] And if it is unique, we can drop the id column too making (filter, information_type) the primary key. [04:23] * StevenK tries to cook up a query showing if there is anything in BugSubscriptionFilterStatus that is duplicated. [04:25] * StevenK reaches for mawson [04:26] stub: yes [04:26] stub: so you think its the cursor, and vacuum is a bystander ? [04:26] stub: this conflicts with some evidence we have - killing the cleanup process doesn't unstick servers that this happens to. [04:27] stub: I don't know why. [04:27] bah [04:27] StevenK: I don't know why (oops-tools 2nd mail) [04:27] lifeless: Have you killed the backend server processes when you have killed the cleanup process? [04:27] They tend to hang around with postgresql unfortunately. [04:28] I think so. Not 100% [04:28] stub: what do you think of the proposed approach anyhow ? [04:28] lifeless: oh, proposed approach is fine. Might take some downtime though unless we much around with triggers and stuff. [04:29] lifeless: Saves us having to run a CLUSTER after to remove the miles and miles of empty pages. [04:30] stub: So it looks like there are guards in place in the model code that avoids the need for UNIQUE. [04:30] stub: (See -ops) [04:30] stub: it looks to me like we could get 4-5 seconds downtime [04:31] stub: just need an index on the session expiry [04:31] wgrant: Did you see https://www.djangoproject.com/weblog/2012/jul/30/security-releases-issued/ ? [04:31] StevenK: Right. So why do we want the data model to allow redundant rows in the table that are totally indistinguishable? [04:31] stub: We don't, and it doesn't at the moment, is what I'm saying. [04:31] stub: step A) index that concurrently; B) copy live sessions, C) copy live sessions again but only those with an expiry time >> (time of previous query + expiry window); D) downtime starts [04:31] lifeless: Which should be added anyway for regular cleaning runs [04:32] StevenK: The proposed data model does. [04:32] stub: You're having a deep discussion with lifeless, prod me when you're done. [04:32] stub: E) copy live sessions again as in C; F) switch tables; G) downtime finishes. [04:35] lifeless: Just going downtime & copying the relevant records across is possibly best. Can do a timing. [04:36] But it isn't the underlying issue, which is that people are seeing behavior in autovacuum that other people don't see. [04:38] stub: other folk do see it, rarely. [04:38] stub: and you may have found a cause :) [04:39] Yes, so fixing the django script to not hold open a cursor might be the best approach. [04:42] That is just a guess though, based on vague comments. Reports of problems are rare, vague and usually for different situations (like the one I'm reading now, to do with TRUNCATE) [04:44] stub: so, see the incident report on the wiki for more info [04:44] stub: I'd like us to design around the risk, if we can, as extended downtime sucks :) [04:45] lifeless: What risk are we designing around? [04:45] stub: that we don't understand the root cause of the problem [04:45] stub: e.g. that it really is just vacuum itself, such as the hidden lock documented to be in 8.4 [04:46] You can't design around vacuum. Vacuum is an integral and required part of PostgreSQL. [04:46] You can't even turn it off entirely, despite the magic option in postgresql.conf that should only ever be used in extremely rare use cases. [04:47] Vacuum getting involved here would be a symptom, not a problem. [04:47] I suspect that the problem is the cursor I old open for up to an hour, which is like a long transaction in many ways. [04:48] stub: we can design around vacuum - e,.g. the bait and switch approach :) That said, its going to be up to you:) [04:48] It is just intuition, but we should probably fix it anyway since we will hopefully not need hour long transactions with pg_dump anyway. [04:49] lifeless: Guess what happens when you fill the new table with data? It gets vacuumed... [04:49] well... analyzed. [04:49] which is autovacuum [04:50] stub: yes, but we've no reason to think autovaccuum is intrinsically a problem [04:50] stub: the data we have is a) big table with b) lots of deletes and c) lots of writes [04:50] I agree we should fix the cursor *too*, because we need to keep the tables trim. [04:51] We also need to run this script daily or more often or we end up in the same situation. [04:51] There is also the question of why we're getting millions of sessions [04:51] I guess I'm saying its not either-or. [04:51] Yes, I agree. [04:53] It would be nice if we can avoid the risks of swapping a new table into place, and having to write the script to do it. [04:56] stub: So if I'm going to change BugSubscriptionInformationType, I'd rather also change BugSubscriptionFilter{Status,Importance} to match. And I don't think I'm up for two primary key swaps. [04:57] The tables probably have about $notverymany rows each, so it's easy. [04:59] wgrant: Haha. 108 in status and 46 in importance [04:59] That's even fewer than I expected. [04:59] I thought maybe a few hundred each [05:00] That's on DF, so condiment to taste [05:00] wgrant: How do I deal with it in the model, though? [05:00] StevenK: __storm_primary__ [05:01] It'll need to be in a separate branch [05:01] Which can land in about 5 minutes [05:01] wgrant: Right, but I do land that first and then the db patch that will DROP COLUMN? [05:02] Right [05:02] Land+deploy the app PK change first [05:02] Or the app will murder you [05:02] * StevenK sorts that out, since it's easy [05:16] StevenK: We can go with the id column, but unless there is a reason it is better to drop it as it is unnecessary and slower. [05:16] I don't recall if there was a rationalization for it with BugSubscriptionInformationType [05:16] At least we're not in too much danger of wraparound :) [05:18] erm... bugsubscriptionfilerstatus, importance [05:20] stub: So I've put up a model change for status and importance that will allow us to drop their IDs [05:20] Then I'm not sure what needs to happen on the DB side [05:22] ALTER TABLE foo DROP COLUMN id; DROP INDEX foo_filter_status_idx; ALTER TABLE foo ADD CONSTRAINT foo_pkey PRIMARY KEY (filter, status); [05:22] Yeah [05:23] Can't use USING, since the index is non-unique for no good reason. [05:23] Right [05:23] And adding the constraint gets us the index too, with unique for good measure. [05:23] Right [05:24] A primary key is basically just a UNIQUE index without any nullable columns. [05:24] wgrant: https://code.launchpad.net/~stevenk/launchpad/no-more-id-for-bsfs/+merge/117374 [05:24] (in postgres) [05:24] StevenK: You're happy with this, or do you have deadlines? I'd like the model fixed, but it seems to have been broken for some time already. [05:24] stub: See above :-) [05:25] StevenK: You've checked around to see that nothing references them? I suspect it's safe, but there might be something. [05:25] Also, you can't spell = [05:25] In the first hunk [05:25] Oh bloody hell, how did I miss THAT [05:26] wgrant: A bzr grep -i 'BugSubscriptionFilterStatus.id' showed up nothing [05:26] StevenK: Have you run the bugsubscriptionfilter tests? [05:27] Although I guess an ec2 run won't hurt [05:27] Since we can't deploy until tomorrow morning anyway [05:27] StevenK: Also, it might want filter_id rather than filter. I forget. [05:28] Haha [05:28] File "/home/steven/launchpad/lp-sourcedeps/eggs/storm-0.19.0.99_lpwithnodatetime_r406-py2.7-linux-x86_64.egg/storm/info.py", line 95, in [05:28] for attr in storm_primary) [05:28] KeyError: 'filter' [05:28] Yeah, we so want filter_id [05:31] AttributeError: 'BugSubscriptionFilterImportance' object has no attribute 'id' [05:31] Hah [05:31] self.assertIsNot(None, bug_sub_filter_importance.id) [05:32] Heh [05:32] That's probably just checking it's been flushed to the store [05:32] It then checks the filter, so it can just check that [05:34] Ah! [05:34] I finally found a test for apport's default private thing. [05:34] I think there's only one. [05:34] Hidden in a doctest [05:34] Hah [05:34] wgrant: I'll be pushing the fixes for that branch in a sec [05:35] StevenK: Will look [05:35] wgrant: Oh, pft. Fully expecting you to get distracted for 45 minutes again. :-P [05:35] Nah [05:35] I solved my issue [05:38] wgrant: Diff updated. [05:38] StevenK: Indeed, r=me [05:38] Thanks [05:40] I guess no-qa is probably okay [05:40] Most certainly. [05:40] lp-land --no-qa if you're feeling reasonably confident [05:41] wgrant: Not like it matters. [05:41] Heh [05:41] It could go through ec2 twice and still land in time. [06:04] stub: https://code.launchpad.net/~stevenk/launchpad/db-drop-id-for-bsns/+merge/117375 [06:30] stub: And the diff for https://code.launchpad.net/~stevenk/launchpad/db-bugsubscriptionfilter-itype/+merge/117003 has been updated. [07:33] stub: so, can you add a card for fixing this sessions issue, and liase with mthaddon on it ? [07:35] lifeless: yes [08:53] lifeless: morning/evening any thoughts on https://bugs.launchpad.net/launchpad/+bug/1022334 https://bugs.launchpad.net/launchpad/+bug/1030584 they both seem rather similar. [08:53] <_mup_> Bug #1022334: data is not saved if launchpad has an error < https://launchpad.net/bugs/1022334 > [08:53] <_mup_> Bug #1030584: Make +filebug timeouts more user-friendly < https://launchpad.net/bugs/1030584 > [08:58] ...back button works fine provided you have JS disabled [08:58] and I didn't think the messing around with "no I need to report a new ug" junk broke that [08:59] was (coincidentally) testing on staging the other day, which nearly always times out first time [09:02] yup, it doesn't lose your description at least [09:02] czajkowski: the second is a confused user, with a real timeout. [09:03] you need to it 'next' again though which is lame. [09:04] so, I don't think we should try to make form resubmital super reliable; thats a browser issue (and IME firefox preserves values just fine) [09:04] we should fix the timeouts when submitting the bugs, and those two bugs have different symptoms [09:04] one is a slow insert the other is a slow packaging query [09:04] there is probably a dupe of that [09:05] hmm ok [09:05] lifeless: going back to "please describe the bug in a few words" does make it *look* like launchpad has lost your bug [09:05] yes, but it hasn't [09:05] the thing is [09:05] its diminishing returns [09:05] even though hitting next unhides it [09:05] say 1 in a thousand timeout on submission [09:05] mgz: not many people would think to hit next [09:06] this is general usability though, not just timeout related [09:06] should we make dealing with the timeout easier, or fix the timeout ? [09:06] mgz: welllll, its a wizard [09:06] so that argument goes both ways [09:06] a one page wizard that resets to the start at the drop of a hat [09:06] with JS off it's much better [09:07] mgz: I'm not sure what your point is. [09:07] because the 'search for similar bugs' and 'fill in all your details' are actually seperate [09:07] I'm clearly not against improvements, but if I had to choose what to work on, the thing they are complaining about (not the timeout itself), isn't what I would do. [09:07] so, you can safely use back and such like without things breaking [09:08] it's like the "error when reporting a bug" issue from the other day [09:08] yes, and that one is terrible and I think we should do better [09:08] because its a common case not an exceptional case. [09:09] my point is it's basically the same thing, I agree for timeouts specifically fixing the timeout is more relevent [09:09] Its similar in a very technical sense [09:09] its not at all similar in a use case sense [09:09] IMNSHO [09:12] so, specifically on czajkowski's question, [09:12] I'd make the first bug a usability one on using back from navigating off the +filebug page (or dupe against an existing bug on that) [09:13] and make the second one about the timeout that wgrant dug up (or dupe against similar +filebug timeout) === matsubara is now known as matsubara-lunch === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === matsubara-lunch is now known as matsubara [13:12] abentley: Hi. Will you be able to QA bug #1018235 today? [13:12] <_mup_> Bug #1018235: TestRunMissingJobs.test_find_missing_ready is disabled due to spurious failures

< https://launchpad.net/bugs/1018235 > [13:12] wgrant: yes. [13:13] Great. === rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 4.0*10^2 === rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: rick_h | Firefighting: - | Critical bugs: 4.0*10^2 [14:35] jml: I finally have some time to look at buildout for you (I've been crazy busy with interviews for the last week). I'm looking at bug 1029715 as well as digesting the comments on https://code.launchpad.net/~james-w/pkgme-service-python/buildout/+merge/116980; if there is anything else I can look at, feel free to let me know [14:35] <_mup_> Bug #1029715: bootstrap.py fails if there is a system-wide install of the desired buildout version < https://launchpad.net/bugs/1029715 > [14:35] benji: thanks :) [14:36] benji: we've just landed buildout for one of our leaf projects, and hope to move up the DAG today or tomorrow, [14:36] benji: will let you know. very much appreciate the help. [14:36] cool [14:38]