[00:00] ah, so the problem is that milestones are not unique [00:01] StevenK, wgrant, mumble? [00:03] sinzui: hi [00:03] sinzui: milestones [00:03] sinzui: are they meant to be per-series ? [00:04] life no, their name space is per project, their parent is a series [00:04] lifeless, ^ [00:04] so its expected folk may have one bug, with two tasks on different series, and the same milestone on both tasks? [00:05] or would that be an unusual use ? [00:05] It is possible. the milestone is the release version. Project release versions are uniqu [00:10] sinzui: so, when you're done with that call [00:10] I'd like to talk through this with you [00:10] to help me solve a quandry [00:12] lifeless, I will be available to talk in ~30 minutes [00:12] excellent [00:12] I will fiddle with lxc containers until you ping me [00:14] Project windmill-devel build #261: STILL FAILING in 41 min: https://lpci.wedontsleep.org/job/windmill-devel/261/ [00:23] sinzui: http://paste.ubuntu.com/630585/ [00:26] Project db-devel build #653: STILL FAILING in 6 hr 9 min: https://lpci.wedontsleep.org/job/db-devel/653/ [00:32] sinzui: http://paste.ubuntu.com/630589/ [00:33] wgrant, thanks [00:35] Project windmill-db-devel build #413: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill-db-devel/413/ [00:38] sinzui: i get this when i try the yui tests - https://pastebin.canonical.com/48843/ [00:39] wallyworld_: Upgrade. [00:56] sinzui: ping me whenever you are ready [00:57] jcsackett, woo [00:57] lifeless, okay [00:58] sinzui: is skype working for you atm ? [00:59] lifeless, I suspect so [00:59] I have sip too [00:59] can we use skype? === StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK | Critical bugs: 205 - 0:[######=_]:256 [01:00] sinzui: I'd prefer skype unless you have a different preference - its echo cancellation is very good [01:14] lifeless, this is not OEM-blessed work, but would it be valuable to remove buildd_secret from the web view? I'd be willing to look into it [01:15] timrc: I think its only visible to admins atm, and useful for debugging [01:15] timrc: IMBW [01:15] lifeless, that's a good point [01:22] sinzui: if another time would be better, thats fine with me; I'm a little blocked till I resolve this however [01:23] lifeless, We love to talk [01:23] sinzui: I cxan't see you on skype [01:25] lifeless, coming online now. [01:25] wgrant: sorry, i exited prematurely. you were still talking [01:26] wallyworld_: Just complaining that libwebkitgtk-3.0-0-dbgsym is 250MB. [01:27] that's quite large for sure [01:27] timrc, furthermore, its the only mechanism to change the buildd_secret if it were to get leaked without having to use SQL. [01:27] timrc, but more importantly, congratz on getting your first change landed! :) [01:30] Project devel build #824: STILL FAILING in 6 hr 32 min: https://lpci.wedontsleep.org/job/devel/824/ === mwhudson_ is now known as mwhudson [02:04] wgrant: I'm available to talk whenever you want about ubuntu disclosure / security bugs [sinzui says you know what this is about but he'll be email you regardless] [02:05] lifeless: I shall await the email. [02:08] sinzui: I have a somewhat symbolised backtrace now. [02:17] sinzui: http://paste.ubuntu.com/630607/ [02:27] hah [02:30] sinzui: http://pastebin.com/85p07rfv makes my test pass; there is no sample data with series milestones outside of debian. ok with this? [02:31] lifeless, I am [02:32] wgrant, thank you very much [02:33] woohoo, its lp-land time [02:33] lifeless: It seems we have a regression. [02:33] lifeless: Probably in flacoste's branch. [02:33] 00134-09052@SQL-launchpad-main-master SELECT SourcePackagePublishingHistory.ancestor, SourcePackagePublishingHistory.archive, SourcePackagePublishingHistory.component, SourcePackagePublishingHistory.datecreated, SourcePackagePublishingHistory.datemadepending, SourcePackagePublishingHistory.datepublished, SourcePackagePublishingHistory.dateremoved, SourcePackagePublishingHistory.datesuperseded, SourcePackagePublishingHistory.distroseries, ... [02:34] ... SourcePackagePublishingHistory.id, SourcePackagePublishingHistory.pocket, SourcePackagePublishingHistory.removal_comment, SourcePackagePublishingHistory.removed_by, SourcePackagePublishingHistory.scheduleddeletiondate, SourcePackagePublishingHistory.section, SourcePackagePublishingHistory.sourcepackagerelease, SourcePackagePublishingHistory.status, SourcePackagePublishingHistory.supersededby FROM Archive, ... [02:34] ... SourcePackagePublishingHistory, SourcePackageRelease WHERE SourcePackagePublishingHistory.archive = Archive.id AND Archive.distribution = 1 AND Archive.purpose IN (1, 4, 7) AND SourcePackagePublishingHistory.sourcepackagerelease = SourcePackageRelease.id AND SourcePackageRelease.sourcepackagename = 31856 AND SourcePackagePublishingHistory.status IN (2, 1) ORDER BY SourcePackagePublishingHistory.id DESC LIMIT 1 [02:34] wgrant: doing what? [02:35] wgrant: it looks like it could be bug 721643 [02:35] <_mup_> Bug #721643: BugTask:+editstatus-page timeout changing source package < https://launchpad.net/bugs/721643 > [02:35] lifeless: It was editstatus, yeah. [02:35] wgrant: changing the source package? [02:36] lifeless: Indeed. [02:36] But the query is different. [02:37] I wonder if the archive join is killing it. [02:37] Previously it named the IDs explicitly. [02:38] 15K archives [02:38] plenty of room for wtfs [02:39] Could you perhaps explainalyze it on staging? [02:39] pastebin the q somewhere for me ? [02:39] or gimve me the oops id ? [02:40] http://paste.ubuntu.com/630614/ [02:44] wgrant: its going to be -terrible- cold [02:44] wgrant: its been running for 4 minutes now [02:44] lifeless: What if you drop the archive join and replace it with archive IN (1, 534)? [02:45] http://paste.ubuntu.com/630616/ [02:45] wgrant: 1.8 seconds hot [02:45] without changing the q [02:46] lifeless: That's still pretty slow. [02:46] lifeless: What if you do change it? [02:46] its not brillirant [02:47] 74ms [02:47] http://paste.ubuntu.com/630617/ [02:48] 74ms isn't brilliant? [02:48] 1800ms isn't brilliant [02:49] wgrant, lifeless would the editstatus timeouts be less of an issue if we completed this bug: https://bugs.launchpad.net/launchpad/+bug/399756 [02:49] <_mup_> Bug #399756: Remove the inline bugtask edit form

< https://launchpad.net/bugs/399756 > [02:49] sinzui: Only marginally. [02:49] sinzui: This query is enough to make a single AJAX request timeout anyway. [02:49] sinzui: I don't think they are related [02:50] sinzui: the inline form doesn't do that much more work [02:50] wgrant: rollback time ? [02:50] wgrant: or hotfix? [02:50] wgrant: (you've looked at flacostes patch already I presume; I haven't) [02:51] lifeless: It's >1000 lines, IIRC. [02:51] So... Hm [02:52] Possibly it's even the 2300 line branch. [02:52] Yay [02:52] * wgrant goes digging. [02:55] Ah, mostly lint fixes. [02:55] But so many :( [02:57] lifeless: So, hotfix is tiny, if we want to. [02:57] I'm not sure if we really want to roll back. [02:57] Given the fun. [02:57] no, its been traumatic [02:58] lets hotfix [02:58] k [02:58] Preparing branch. [02:58] preparing incident report [02:59] Thanks. [03:03] bug # ? [03:03] None as yet. [03:03] Will file if you want. [03:03] But you seem to be handling the paperwork fine :P [03:03] thanks :( [03:03] and today I was finally hoping to do microservices. [03:04] Well, what did you expect after 6 days :( [03:04] epic fail? [03:04] Yes. [03:04] what rev broke stuff? [03:04] and whats the OOPS id you have? [03:05] 13263, OOPS-1999DR15 [03:05] Probably not synced yet. [03:05] But carob:~wgrant/logs/soybean/2011-06-22/05353.DR15, if you want it. [03:06] nah [03:06] just for the paperwork [03:06] bug 800485 [03:06] <_mup_> Bug #800485: timeout changing sourcepackage names in bugs < https://launchpad.net/bugs/800485 > [03:06] Thanks. [03:07] Tests pass with the fix, unsurprisingly. [03:07] http://paste.ubuntu.com/630623/ [03:07] diff ? [03:07] thanks [03:07] doit [03:08] this may help that other timeout? or is it undoing a spurious change flacoste made? [03:08] The latter. [03:09] He Stormified the query, and changed it to use a nice join instead of nasty all_distro_archive_ids. [03:09] But again, it has caused a performance issue :( [03:09] Probably because SPPH is so skewed. [03:10] ah [03:53] sinzui: And what about apport bugs? :) [03:55] wgrant, I do not know. Some or public some are private. I do not know its rules,, but I do not need to know why some of my bugs are private if we make apport behave like the current web UI [03:55] The bugs are created private since the backtrace may contain private information. [03:56] I wish apport was smart enough to know I do not have personal information in the bug an I really do want someone to see it [03:56] The bugs start with only the robot subscribed. It processes the coredump into a retracted backtrace. [03:57] It then makes a decision as to whether the backtrace should be kept private. [03:57] If so, it subscribes the crash bug triagers. [03:57] So apports visibility rules are not directly affected since they are not flagged as secuirty [03:57] if not, it makes the bug public. [03:57] sinzui: Right, but this would give Ubuntu owners direct access to sensitive passwords. [03:57] So it is a change of behaviour. [03:58] all six people? [03:58] Project parallel-test build #58: STILL FAILING in 1 hr 1 min: https://lpci.wedontsleep.org/job/parallel-test/58/ [03:59] wgrant, how can they not see them now? because they are not bug supervisors? They can change that at any moment [03:59] sinzui: Hm? [03:59] sinzui: Apport reports bugs with only the robot and the reporter subscribed. [03:59] No bug supervisor is involved. [03:59] ah, sorry. I misunderstood that. [04:01] This somewhat relates to the IRobot discussion. I think the case here is that bug report is not finalised so is not in a full state. [04:01] It's more similar to the security case. [04:01] Which suggests that the security case is not really that special. [04:02] Which suggests that it should not be much of a special case. [04:03] "Launchpad requires that the project maintain(er) be a member of bug supervisor team." <-- I don't believe this is currently true. Are you proposing it become true? [04:03] I think privacy mean personal data, which is the cited reason for hiding the bugs. [04:04] cody-somerville, it is true, but I know how to break the rule. We have lots of orphaned bugs because the maintain changed *after* the bug supervisor was set [04:04] It is not true. [04:04] The fields are unrelated. [04:04] Except that the maintainer can change the bug supervisor. [04:05] I can set the supervisor to myself or a team I am in. I cannot set it to another team [04:05] back [04:07] Nope still cannot make ~zeitgeist mange the bugs in py projects [04:07] sinzui: or a team you own ? [04:08] lifeless, I must be a team admin [04:08] sinzui: ownership grants Launchpad.Admin [04:09] Yes, that also mean I can make myself a member when ever I chose. I did that two weeks ago and bac could not stop me [04:09] sinzui: yup, thats what we agreed on wasn't it ? [04:10] yes it was. [04:10] I do wonder, perhaps project owners should be able to set any team as supervisor [04:10] I have all the access I want [04:10] but thats a different discussion [04:11] testblahblah might be a junk project :( [04:12] I think users need to say they need to do that. Ubuntu and canonical projects use bugs and security differently than everyone else [04:24] Project windmill-db-devel build #414: STILL FAILING in 1 hr 13 min: https://lpci.wedontsleep.org/job/windmill-db-devel/414/ [04:27] sinzui: I have replied [04:27] sinzui: I have some bits I don't understand yet [04:27] sinzui: and perhaps some confusion [04:28] sinzui: I think apport is quite easily fixable in the very short term, with a crash db being the long term fix. [04:33] People don't read :( [04:33] /projects/+new says "You do not need to register a project to: [...] Activate a PPA" [04:49] StevenK, wgrant: mind if I restart the appserver on dogfood? [04:51] jtv: Please do. [04:51] thanks [04:55] lifeless: The primary archive does use a-f. [04:56] wgrant: the bug is about ppas [05:03] lifeless: But the slowness that Julian speaks of is a-f. [05:04] yes [05:04] I read the cache comment as 'can you not jus tuse a-ft with a cache db to get ppa contents.gz working [05:04] ' [05:04] to which the answer is no, we don't use a-f for ppa contents.gz [05:07] wgrant: do I have something wrong in that logic? [05:07] Project windmill-devel build #262: STILL FAILING in 1 hr 6 min: https://lpci.wedontsleep.org/job/windmill-devel/262/ [05:08] lifeless: Right, we do not use a-f for PPAs [05:08] lifeless: Who is asking about Contents for PPAs? [05:08] there was a comment in the bug about it [05:09] https://bugs.launchpad.net/launchpad/+bug/796997 is tracking my work on it, but it *will* be slow going. [05:09] <_mup_> Bug #796997: Contents generation should be done from the database

< https://launchpad.net/bugs/796997 > [05:09] StevenK: yeah, its fine [05:09] he was suggesting using a-f with the cache switch, which is just irrelevant for contents.gz w/ ppas [05:10] I doubt I can populate BRPC for a bit. 6.6 million BPRs with unexpired .debs [05:10] yeah [05:11] its pending the disk space increase as much as anything [05:11] Right [05:11] I figure I can take it slow, wait for db-stable to get merged into devel, and work from that. [05:11] sure [05:11] though if you are not modifying existing tables, you can add the new ones live [05:11] no downtime [05:12] * StevenK shrugs [05:12] My brain is hardwired for "any changes to the db == db-devel" [05:13] hopefully that will be history in a few weeks. [05:13] Excellent. Then I can progres to "any change to the db == " *SEGV* [05:14] I have a play branch, I'll be hitting up mawson probably at the sprint [06:08] Hahaha [06:10] Hmm? [06:10] http://people.canonical.com/~wgrant/launchpad/big-plans.png [06:10] Should I be scared? [06:10] Bwahaa [06:10] Grar. [06:11] RT [06:11] DIE [06:11] I can't Cc myself to stuff :( [06:11] So, let's see this query plan. [06:11] It is obscene. [06:12] Perhaps we just want to bite the bullet and create a summary table. [06:15] 404 [06:16] wgrant: what situation ? [06:17] lifeless: Efficient querying of binary and source publication presence and overrides. [06:17] lifeless: By name. [06:17] At the moment we have to join through BPR to BPPH. [06:17] yes [06:17] Since there's no name on BPPH. [06:17] Can denorm that onto it [06:17] Probably. [06:17] if that will fix the queries, its a perfectly cromulent solution [06:17] Guess it wouldn't be that big. [06:18] Let's see what happens... [06:19] wgrant: what was the png ? [06:20] lifeless: A half-fullscreen terminal. [06:20] Amusing, is what it was. [06:20] The top half has the word QUERY in it. [06:20] The bottom half was the seperator at the top of the table. [06:20] heh [06:20] None of the actual plan fit on the screen. [06:20] Because it is so hideous. [06:20] HIDEOUS [06:20] Let's see if mawson melts... [06:24] Project db-devel build #654: STILL FAILING in 5 hr 58 min: https://lpci.wedontsleep.org/job/db-devel/654/ [07:07] Yippie, build fixed! [07:07] Project devel build #825: FIXED in 5 hr 37 min: https://lpci.wedontsleep.org/job/devel/825/ [07:10] Hm. [07:10] So those two persistent codeimport failures are gone? [07:12] I think they've moved from persistent to spurious [07:12] Wait, wrong word :-/ [07:12] s/spurious/intermittent/? [07:12] Right [07:43] StevenK, wgrant: either of you willing to offer a shoulder to cry on? Got a bit of a soyuz question. [07:43] jtv: Fire away [07:44] Thanks. It's about how the +queue view batch-loads the various items associated with a batch of PackageUploads. [07:44] Oh dear. [07:44] "Slowly" [07:44] "Awkwardly" [07:44] AFAICT it retrieves the PackageUploadBuilds in self.builds_dict. [07:45] That starts with BinaryPackageReleases. [07:45] I guess working on LP eventually does eventually need a shoulder to cry on. [07:45] From there, it collects the builds. [07:45] * jtv looks up what those are [07:45] nigelb: Particularly Soyuz, yeah. [07:45] jtv: Odd, it shouldn't be able to start with BinaryPackageReleases. [07:45] BinaryPackageBuilds. [07:45] wgrant: And here I thought Blueprints were bad. [07:45] jtv: Since it goes PU -> PUB -> BPB -> BPB [07:45] BPB -> BPR, sorry. [07:46] Don't worry, I hadn't gotten that far yet. :) What's the correct line then? [07:46] ? [07:46] PU → PUB → BPB → BPR? [07:46] Yes. [07:46] * jtv decodes [07:46] Ah yes [07:47] In my case, I'm more interested in the SPR than the BPR but it's much the same story otherwise. [07:47] PUS → PUS → SPR [07:47] Grar [07:47] PU → PUS → SPR [07:47] I thought the FKs go PU ← BUB → BPB → SPR [07:47] One of your arrows is backward [07:47] No, it's right. [07:48] Don't worry about the PUS; I think those aren't related to my current problem. [07:48] PU ← PUB → BPB ← BPR [07:48] I'm interested in the chain from PUB to SPR. [07:48] Why? [07:48] That's not normally something you want to do. [07:48] * jtv images the rest of the LP team looking on in bafflement [07:49] In this particular case, I need to find the PS. [07:49] Packageset, sorry. [07:49] Normally it'd be PU ← PUS → SPR → SPR [07:49] Ah. [07:49] SPR -> SPR? WTF? [07:49] StevenK: ISWYM [07:49] StevenK: SourcePackageRelease → SourcePackageRecipe [07:49] Except I am wrong. [07:49] OIC — WTF indeed [07:50] PU ← PUS → SPR → SPRB → SPR [07:50] Right [07:50] jtv: So, for a source upload you wouldn't go near PUB. [07:50] Why are you trying to? [07:51] I'm not saying it has to be a source upload. [07:51] AssertionError: [] is not [] [07:51] Why would there even be a PUB for a source upload? [07:51] Sorry?! [07:51] jtv: There wouldn't be. But I'm not sure we care about Packagesets for binary uploads now. [07:51] StevenK: you're creating empty list objects with different identities. [07:51] jtv: If you want to, it's PU ← PUB → BPB → SPR [07:51] Oh, right [07:51] Sigh [07:51] Stupid Python [07:52] wgrant: true—maybe I should go back to what my real problem is. [07:52] Which is that I'm missing the packageset "core" for a PU for netapplet 0.99.6-1 in the sample data. [07:52] (Fun with doctests) [07:53] jtv: What have you changed? [07:53] Is it a mixed upload? [07:53] I'm not sure. It's listed as (source) but that may be sort of a straw to clutch at. [07:54] The packagesets do work for alsa-utils, which also says it's (source). [07:54] And the packgesets look pretty simple to me, when it comes to source uploads. [07:54] Ahhh, maybe they're not actually. [07:55] Because again, the view doesn't go straight through the PUS to get the SPR. It goes through SPRF. [07:55] Hm? SPRF is at the end. [07:56] After SPR [07:58] Should be, yes. [07:59] That's what you get when documentation simply says things like "a list of SPRs" without being precise about which ones they are. [08:00] Hm? [08:01] good morning [08:02] hi adeuring [08:02] hi jtv! [08:03] wgrant: I can see now that the view probably needs a bit of tightening up of these access routes. It should bulk-load classes in a more sensible step-by-step manner, following the primary access paths. [08:03] jtv: Indeed. It was one of the earlier places to do preloading. [08:04] I think I walked into a trap because I wasn't familiar with the "natural" access paths. That's going to be a growing risk, or source of friction, with squads. [08:05] Mm. [08:05] Everyone will be familiar with the model eventually. [08:08] But how long will it take and how hard will it be? [08:08] A while and not terribly. [08:09] I even know translations somewhat now. [08:09] I suspect the rest of LP is relatively easy when you started with soyuz! [08:09] Fair point. [08:10] Also, I'm pretty sure that a lot of the Soyuz knowledge will suffer from degrading memory _and_ code changes after a few rotations on other stuff. [08:11] I don't know about others, but it's pretty irrevocably scarred into my mind. [08:11] Good, that's one innocence ruined; who's next? [08:11] I think an investment in clarity here would pay off handsomely, both in terms of performance and in terms of developer effectiveness. [08:12] \o/ got that test passing! [08:12] Wonder how many others I broke. [08:12] What criminal act have you performed on the view? [08:13] Bulk-loaded PUS, SPR, Packageset. [08:13] Also, we have put… a bag over its head. [08:13] Ah, excellent. [08:13] (Because the Blackadder angle was just too good to resist) [08:14] I had a branch that trialled that long, long ago. Before it was accepted that we could bulk-load collections. [08:14] Because it issues so many queries :( [08:14] Quite. [08:14] I suspect some of the complexity would evaporate from that view if we would just take the bulk-loading one step at a time. [08:15] It needs to be ripped out and replaced. [08:15] Right now there's a fair amount of "I've got objects at step 1 in the reference chain; get me the ones at step 3." [08:15] The bulk-loading is rather messy. [08:15] Needs to be redone with helpers. [08:15] Well yes, ripping out would feel good too. [08:15] And sense. [08:16] One thing that bothers me about the whole thing is that we _could_ fetch the PUS/PUB/PUC and so on in Ajax as you fold open one queue item in the UI, _but_ we still need to know that they're there so we can decorate each with the right icons. [08:16] Which reminds me… [08:16] Yes. [08:16] They're very cheap to get, though. [08:16] Just have to remove the scaling. [08:16] …do we have any icon that we might use to represent a package sync? [08:16] We do not. [08:16] I think Julian was going to talk to Huw about that. [08:16] Or something. [08:16] but it's been a while. [08:17] You see we're sort of scratching for icons already. [08:17] Which is why we use the Ubuntu logo for translations... [08:17] Maybe not translations. [08:17] Maybe it was dist-upgraders and debian-installerse. [08:17] (The page could also do with some sprites) [08:17] But something that shouldn't have the Ubuntu logo, anyway. [08:17] Yes, saw some of that. [08:17] Actually it's quite easy to see in my new code: [08:18] I've got a method that says "here's a list of icons you may need; for each you get condition, alt, title, image name. Now spit out HTML for the ones that apply." [08:18] Excellent. [08:19] I'm hoping that a future step could also notice that "hang on, I have a sprite for this somewhere." [08:19]