=== matsubara is now known as matsubara-afk [02:22] wgrant: there's a couple of criticals for timeouts doing the most simple updates to the bug table eg update bug set description = "blah" where id = 234. that took 8s. we should be able to close these as a one off you think? [02:25] wallyworld_: Not for writes, no [02:25] wallyworld_: Long trivial reads are The Glitch™, but writes tend to be locks [02:25] Which are a real issue that warrants investigation [02:26] difficult given how infrequently it seems to happen [02:26] Well [02:26] We can put in place monitoring [02:26] To track down long invasive locks [02:26] But indeed. [02:27] and it seems sporadic - 3 bugs, 3 different single inserts, 3 different tables [02:27] Which bugs? [02:27] bug 1059853 [02:27] <_mup_> Bug #1059853: BugTask:+editstatus timeout blocked on bug update setting heat < https://launchpad.net/bugs/1059853 > [02:27] Often we'll have multiple OOPSes [02:27] bug 1048984 [02:27] Which suggest it's not just The Glitch [02:27] <_mup_> Bug #1048984: BugTask:+edit timeout < https://launchpad.net/bugs/1048984 > [02:27] But obviously writes *can* be affected by The Glitch too [02:28] bug 1028105 [02:28] <_mup_> Bug #1028105: BugTask:+editstatus slow inserting BugMessage < https://launchpad.net/bugs/1028105 > [02:28] So, all of those could conceivably be long Person locks [02:29] how is updating a bug description affected by a person lock? [02:31] Ah, true, the description change couldn't be affected [02:31] But the BugMessage one probably is [02:31] Due to the FK to person [02:31] If you're inserting a new row, or changing the value of the owner column, it will conflict with a write lock on the referenced person row [02:32] do we know what holds long write locks on Person? [02:32] But the UPDATE Bug SET date_last_updated=%s, description=%s WHERE Bug.id = %s; can indeed not be affected by that [02:32] It must be either a glitch or a lock on the bug row itself [02:32] All three could be explained by a lock on the bug row. [02:32] sure. finding out what is the root cause will be difficult === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [07:28] good morning === frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: frankban | Firefighting: - | Critical bugs: ~260 === rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: frankban, rick_h | Firefighting: - | Critical bugs: ~260 === al-maisan is now known as almaisan-away === matsubara-afk is now known as matsubara [14:12] jcsackett, do you have time to hangout [14:12] sinzui: sure, give me a moment to locate my phone. [14:23] sinzui: Do you know whether the ProductReleaseFinder should consider non-public products? [14:25] abentley: r=me but didn't mark approve since you mentioned some stray test failures in the stand up [14:25] rick_h_: Thanks. I've nailed down most of the test failures now, just got ProductReleaseFinder to worry about. [14:26] abentley: k [14:29] abentley, I am confident that the answer is no [14:29] sinzui: Thanks. [14:30] abentley, I don't think they should be permitted to have releases...but that can be debated. they should not be permitted to have a release_file_glob. [14:31] frankban, rick_h_: could one of you please review this MP: https://code.launchpad.net/~adeuring/launchpad/milestone-sec-adapter/+merge/129907 ? [14:32] adeuring: sure thing, will take a look [14:32] adeuring: is the QA on the other branch all ok? [14:32] rick_h_: I've pushed r16113, which has no known test failures. [14:32] rick_h_: just marked it as OK [14:32] adeuring: awesome thanks [14:32] rick_h_: ...and I noticed a bunch of merge conflicts in the new branch... [14:33] adeuring: in the milestone one? [14:33] rick_h_: yes [14:33] adeuring: ok cool, will work on getting the deploy done while you peek at that then [14:33] rick_h_: sounds good [14:51] rick_h_: I created a new branch & MP: https://code.launchpad.net/~adeuring/launchpad/milestone-sec-adapter/+merge/129917 (was easier create a new branch than to update a somewhat outdated one...) [14:52] adeuring: rgr [15:06] adeuring: is + self.assertRaises(Unauthorized, getattr, obj, name) [15:06] oops [15:06] adeuring: is Authorzized a german thing? At first I thought it was a typo but it's consistantly repeated [15:06] rick_h_: nah, that's an oridnary typo ;) [15:07] ah ok, well you're darn consistant with it and got me wondering :) [15:07] is you're going to tyop, it's best to do it consistently! [15:07] I'll fix it [15:07] adeuring: np, noting them in the comments [15:08] mgz: exactly! Get them thinking [15:17] adeuring: r=me with some typo and a question [15:17] rick_h_: thanks! [15:17] thanks for the comments to help me along! [15:32] adeuring: on the check vs the db constraint, I just bring it up as a general case of check what you want to check directly in case things come along later and you get more than you meant to at a later date [15:33] rick_h_: could you explain this a bit more? [15:34] adeuring: so right now there's two cases, product nad distribution. [15:34] right [15:34] later, let's say someone adds distroseries (not that it would in this case) [15:34] your check is against product, so now two things would match, distribution and the newly added distroseries [15:34] because you were only checking that product is None [15:35] in this case, I guess it's unlikely to be expanded to other items, but as a general rule of thumb, if you want to make sure it's not a distribution I'd word it as self.distribution is not None [15:35] vs the indirect product is None [15:37] rick_h_: ok, in that case we would anyway need to distinguish the cases for distribtuion and distroseries. The current check for "prodct is not None" has in this case the advantage that it prvents a failure for the case that distribution _and_ product are none because distroseries is not none [15:38] adeuring: right, but you'd hit a failure and then make sure you take the new condition into account vs silently passing successfully [15:38] adeuring: sorry, it's just a general comment and nothing in particular in this case. [15:38] rick_h_: ok ;) and ISTM that we have different kinds of failure in mind ;) === frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: rick_h | Firefighting: - | Critical bugs: ~260 === deryck is now known as deryck[lunch] [16:58] rick_h_: I'm going on lunch, but could you please review https://code.launchpad.net/~abentley/launchpad/user-blueprints-tests/+merge/129944 and https://code.launchpad.net/~abentley/launchpad/user-blueprints/+merge/129945 ? They are two steps in the same work. === matsubara is now known as matsubara-lunch [16:59] abentley: loading up === deryck[lunch] is now known as deryck === matsubara-lunch is now known as matsubara [18:19] Question: we have a user using syncSources() to copy over binary packages from a source PPA to a target PPA. The issue we are encountering is that if syncSources() runs and all arches are not already built in the source PPA, they apparently get built in the target PPA. When the arch finishes building in the source PPA syncSources apparently will not overwrite what was built in the target PPA [18:19] In our case it's imperative that the package is identical between the two PPAs [18:20] He's currently having to add additional logic to his script to ensure syncSources is only called once all arches are built [18:20] Is this a bug in LP or expected behavior? [18:29] timrc: Somewhat expected. You may be interested in lp-promote-ppa in lp:hydrazine [18:30] (Pre written cli script for this use case) [18:32] maxb, I'll check it out. Thanks for the tip [18:46] rick_h_: private-product-listings is on devel now, so you should be able to merge and use it. [18:52] abentley: awesome thanks === rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: ~260 [18:54] wgrant: ~abentley/launchpad/user-blueprints is in EC2. === Ursinha_ is now known as Ursinha [19:26] timrc: By the way, is there a reason you're still using syncSources (which will almost certainly time out lots) and not copyPackages? Not that it will IIRC make a difference to this bug, but still. [19:26] s/bug/behaviour/ [19:28] deryck: There's no OCR. Could you please review https://code.launchpad.net/~abentley/launchpad/user-blueprints-privacy/+merge/129967 ? [19:31] cjwatson: syncSources generally works just fine for a single source. In that scenario, it is highly desirable to receive synchronous feedback [19:33] cjwatson, Not sure why this particular user chose syncSources over copyPackages [19:33] For a script writer's usage, syncSources is better [19:34] Unless you're trying to sync something like the linux kernel, for which LP really is going to time out [19:34] Why are you using syncSources rather than syncSource for a single source? :-) [19:34] we use syncSource for a single, small, package in PES to copy a keyring package into PPAs that are created through one of our interfaces. Works well enough. I could see the concern if we were copying a lot of packages, though. [19:34] syncSource I can more or less understand. copyPackage and copyPackages I can certainly understand. syncSources not so much. [19:35] syncSource(s) / copyPackage(s) seem like poor choices for name when taken together [19:36] s/name/naming/ [19:36] abentley, sure, I can review. [19:36] deryck: Thanks. [19:36] np [19:37] deryck: rick_h_ already did the hard bits. [19:38] timrc: Yes, they grew organically rather than being designed. Once in place, of course, good APIs don't change. [19:38] (Not designed as a whole, I mean. Of course they were designed individually.) [19:39] I really wish copyPackage/syncPackage had a flag that could be specified that would fail the operation if not all arches were yet built for the package in question [19:40] abentley, yeah, that wasn't bad at all. easy peasy. r=me. [19:40] it does seem like a bug to me if what you're trying to express is "copy but don't rebuild this package" only to do just that [19:41] cjwatson, they change, hence versioning... [19:41] seems like we decided to stop at 1.0 oh and default to devel, though [19:41] deryck: thanks. We're over our WIP limit on QA, so I'll hold off landing for now. [19:41] timrc: Yeah, but in reality it would be very inconvenient for little real benefit [19:42] timrc: Ubuntu uses copyPackage(s) *extensively* [19:42] abentley, abel's should have moved across, sorry. I updated the board. [19:43] deryck: Cool. [19:45] cjwatson, Yeah and our use of PPAs is not exactly what they were intended for, so I'm willing to cut some slack :D === Ursinha is now known as Ursinha-afk === matsubara is now known as matsubara-dinner [22:47] sinzui: around? [22:47] I am [22:47] sinzui: Could you do me a favour and create a proprietary project on qastaging so I can test my fix for https://qastaging.launchpad.net/projects/+review-licenses ? [22:48] okay [22:49] abentley, reload. I created https://qastaging.launchpad.net/aaron-curtis-test [22:50] sinzui: I see nothing new, but it's not broken. Win. Thanks. [22:50] yep [22:51] sinzui, abentley: That project doesn't look private [22:51] All its sharing polices are public [22:51] "Information Type: Public" [22:52] sinzui: Yes, I can see the project under /projects, for example. [22:53] oh, I made a commercial project, not a public one. [22:53] I suck [22:53] * sinzui tries again [22:53] It's Proprietary now [22:53] sinzui: I want a proprietary one. [22:53] I will do both [22:55] Strangely, I seem to be able to navigate to https://qastaging.launchpad.net/aaron-curtis-test but I don't see it listed at https://qastaging.launchpad.net/projects [22:56] As I mentioned in the review, it's because Product.userCanView lets ~registry see private projects [22:56] Which doesn't really make sense [22:57] I did it right the first time https://qastaging.launchpad.net/aaron-curtis-test-2 [22:59] sinzui: Okay, I don't see either one listed, but I can navigate to both. I'll call qa-ok on this code, but I'll make sure we have a bug for this registry issue. [22:59] I see it as a CA [23:00] * sinzui is happy [23:00] sinzui: But you would also see it as product owner. You should be able to see BzrTools as CA. [23:01] abentley, I see your private tests :)