[00:23] * wgrant fires off a full test suite run in an oneiric container. [00:25] Hmm. [00:26] mailman does not like the distutils installation :( [00:26] Ahh. [00:26] * G looks to see who the OCR is today [00:29] G: I'm not, but what needs reviewing? [00:29] oh, not online yet [00:29] wgrant: I've got a branch for Bug #697157 [00:29] <_mup_> Bug #697157: Streamline "You have assigned this bug to yourself" message < https://launchpad.net/bugs/697157 > [00:30] existing message for all cases except "You have assigned this bug to yourself" if you assigned it to yourself [00:30] I'm just going to propose it [00:44] wgrant: https://code.launchpad.net/~dev-nigelj/launchpad/bug-697157/+merge/74035 [00:47] G: That seems like it will miss the case where it's assigned then unassigned quickly, once we move to queuing these (as we should). But you probably don't have enough information to detect that, so I guess it's reasonable. [00:48] wgrant: hmmm I hadn't thought of that case [00:49] wgrant: that said, wouldn't the method that e-mail is generated with change slightly if/when that happens [00:50] I didn't poke too much into how the scripted bugmail is generated, so I'd have to take another look at that but just thinking along that line === mwhudson_ is now known as mwhudson === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 254 - 0:[#######=]:256 [01:20] /wrists [01:21] And since we probably won't deploy for 48 hours or so, we should break the graph shortly :) [01:47] ouch [01:49] wgrant: Declaring destroy-openidrp ready for a review. I will poke stub when he surfaces. [01:52] StevenK: But it doesn't have DB changes, does it? [01:54] wgrant: It does not, but stub is OCR. :_P [01:55] I'm heading out, can someone ask stub to have a look at my MR? [01:57] wgrant: Do you think it's safe or unsafe to destroy the bazaar-experts team? [01:58] StevenK: Safe. We've deployed everything except librarian1 since then, AFAIK. [01:58] And if librarian1 needs bazaar-experts, then it should blow up, because something is seriously screwed. [03:01] wallyworld_: Have you tried to run tests on oneiric yet? rabbitfixture doesn't support rabbitmq-server 2.5.0. [03:01] I think I have a fix. [03:01] Need to test it on lucid too, though. [03:02] wgrant: i've only run some yui tests and they went ok [03:02] but nothong with rabbit [03:02] wgrant: i'm pissed off ay qas. it keeps timing out for a simple operation :-( [03:03] :( [03:04] hard to know whether to qa-ok it. the sql is fine [03:09] wallyworld_: Is this the bug privacy thing? [03:09] That's not a simple operation :) [03:09] Aha, got a rabbitfixture regex that works on both lucid and oneiric. [03:09] But is a bit evil. [03:11] Test attempt #2 [03:16] wgrant: yes, the bug privacy thing. the sql before and after the change is similar, except the fix has a couple of extra selects to update the subscription portal. [03:17] wgrant: it works fine if i edit a bug that's on a smaller project than lp [03:17] so i'm marking it as ok [03:17] but, in testing, i found a bug that i confirmed is also on lp.net [03:18] but it's not a result of any disclosure work so i'm not sure if we'll end up fixing it [03:36] wallyworld_: What's the bug? [03:36] wgrant: bug 841511 [03:36] <_mup_> Bug #841511: javascript error when changing a bug's security status < https://launchpad.net/bugs/841511 > [03:37] wgrant: it's in the same area of code as i was qa'ing so i had to look at diffs and also try it out on lp.net and found that it's an unrelated problem [03:38] i should just assign myself to the bug and fix it === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 255 - 0:[#######=]:256 [04:06] Someone promote a high to critical ... [04:07] I'm just looking for one. [04:07] Morning [04:07] 255? :( === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 257 - 0:[########** stack smashing detected : ./lp terminated [04:11] BAH! [04:12] * ajmitch thought that number was meant to be going down [04:12] Actually, I'm not sure if 256 was right. [04:12] Because there were bugs fixed and newer bugs added. [04:13] http://webnumbr.com/launchpad-critical-bugs is what that number goes by. I just added two because I bumped two OOPSes that had been forgotten to critical. [04:13] The real number is significantly higher, as several are private. [04:14] No, I meant the 256 that acted as the target from which you startred [04:15] Ah/ [04:16] Now, it seems as though there was no progress. [04:16] That's bad. [04:16] There was no progress; that is bad :) [04:17] Huh? [04:17] But Francis had this graph which said there were bugs closed as well as new ones opened. [04:17] Well, yes, lots were closed. But lots more were found, and not all of them were new. [04:17] I refuse to believe there was no progress. You guys aren't /that/ bad ;) [04:26] there has been progress, things have improved, but they haven't progressed in the intended direction of reducing the number of criticals [04:30] Ah :( [04:34] so what, focus urgently on Critical bugs eh? [04:37] I spent two hours on this bug yesterday, 66345 [04:37] eventually I realized its probably a bug in that library. [04:37] Bug #66345 [04:37] <_mup_> Bug #66345: alt="" in dependency charts makes them poorly accessible

< https://launchpad.net/bugs/66345 > [04:38] Hmm. [04:38] * StevenK looks for a critical, since the DSP vocab work is still blocked, and his two other branches are waiting for others [04:39] * G spent ages trying to understand the API to fix a Medium bug, must try again now [04:41] Isn't bug 669296 mostly fixed? [04:41] <_mup_> Bug #669296: App servers die and hang < https://launchpad.net/bugs/669296 > [04:41] StevenK: three died over the weekend. [04:41] But it is much better now that logrotation is fixed. [04:41] First time it's happened in weeks, I think. [04:42] Rarrrgh buildbot is broken again. [04:42] Tempting to roll back the three bzr revisions from the last couple of weeks. [04:42] Hmm. Except that this looks like a dependency issue. [04:43] Is this okay to fix? bug 99593 [04:43] <_mup_> Bug #99593: Package names in search results should be linked

< https://launchpad.net/bugs/99593 > [04:43] I'm not sure if I want it fixed :D [04:43] nigelb: The next scheduled feature involves reworking bug listings. [04:44] Ah, and it's even tagged (bug-columns). [04:44] So I would avoid it. [04:44] okay :) [04:44] * nigelb is /very/glad he asked [04:46] I can't reproduce bug 750384 in my setup. [04:46] <_mup_> Bug #750384: After muting with Bug:+mute, you get redirected to +subscribe < https://launchpad.net/bugs/750384 > [04:46] (devel) [04:46] Could someone else confirm so I can close it. [04:46] yeah I looked at that one [04:46] can't reproduce either [04:46] Excellent. [04:47] I meant to note it, but couldn't help but think I was doing something majorly wrong :) [04:47] poolie: O hai -- you reviewed the Twisted patch for bug 703807, should we cherry-pick it, or wait for a upstream release? [04:47] <_mup_> Bug #703807: launchpad sometimes serves download files as content-type text/html

< https://launchpad.net/bugs/703807 > [04:47] hi stevenk [04:47] I have this feeling that there are multiple bugs about that issue [04:47] good question [04:48] well, it has certainly been duped several times [04:48] and perhaps caused some confusion or questions short of filing a bug [04:48] so python at the moment comes from an egg? [04:50] stevenk i guess the questions are [04:50] - how soon will we get an upstream release [04:50] bug 174224 looks like a dupe [04:50] <_mup_> Bug #174224: launchpadlibrarian sends wrong content-type header

< https://launchpad.net/bugs/174224 > [04:50] - how much do we care about getting it done soon vs later [04:50] - how much more work is it to cherry-pick? [04:50] possibly bug 645924 [04:50] <_mup_> Bug #645924: .tar.xz files are served with text/plain content-type by launchpadlibrarian

< https://launchpad.net/bugs/645924 > [04:51] StevenK: None of those are dupes. [04:52] in the thing i helpde fix in twisted, it would specifically give you text/html i think [04:52] Right. [04:53] i suspect the first of them is just obsolete [04:54] poolie: So, I don't think we can answer how soon we get an upstream release; I'm not sure about making a cherry-pick release of Twisted ... [04:54] It is easier to just wait [04:55] Can someone help me understand bug 294050? [04:55] <_mup_> Bug #294050: Please add links for entries in the revision feed for a person

< https://launchpad.net/bugs/294050 > [04:55] I think it means the feeds in branches. [04:55] But I already see links to loggerhead [04:55] whoa, feeds [04:56] heh, that's not improving my sinking feeling :) [04:56] so, i can help you understand it [04:57] Excellent. [04:57] OH! I know what I can remove [04:57] which is that basically it's about inserting a hyperlink, i guess pointing to loggerhead, into the revision feed data [04:57] DELAYED COPIES [04:57] however, i don't know if revision feeds are a very useful feature [04:57] i never look at them any more [04:57] poolie: I already see it everywhere I look. [04:57] oh, in the feed? [04:57] yeah [04:58] then maybe you should just close this [04:58] so, is it something wrong in how I perceive the bug. [04:59] For example, in here I can see links http://feeds.launchpad.net/~launchpad-pqm/launchpad/devel/branch.atom [04:59] Aha, let me close the bug then :) [04:59] go you [04:59] StevenK, i can still reproduce bug 645924 [04:59] <_mup_> Bug #645924: .tar.xz files are served with text/plain content-type by launchpadlibrarian

< https://launchpad.net/bugs/645924 > [05:00] i suspect it actually does have c-t text/plain in the librarian [05:00] poolie: What's the LFA ID? [05:00] i guess it's 56261240 from the url? [05:01] SELECT mimetype from libraryfilealias where id = 56261240; => text/plain [05:01] yep [05:01] So the sniffer is (or was) bad. [05:01] so [05:01] if you add a new upload what does it get? [05:01] I don't recall if we trust the browser or not. [05:03] * poolie looks at other .tar.xz files [05:03] Hold on, I can do it faster [05:03] i'm looking through the staging db [05:04] so, only if you can type faster [05:04] or know the schema better [05:04] either is possible [05:04] I have a query running, so let's see :-) [05:05] SELECT distinct(mimetype) from libraryfilealias where filename like '%.tar.xz'; [05:05] almost all are application/octet-stream, it seems. [05:06] application/octet-stream and text/plain [05:06] I've been looking at https://bugs.launchpad.net/launchpad/+bug/674854 can't help notice that https://api.launchpad.dev/devel/ubuntu/hoary/architectures is a bit funny... total_size: 3, entries: [] [05:06] <_mup_> Bug #674854: [API] Add a way to get the list of "supported" architectures for each release

< https://launchpad.net/bugs/674854 > [05:06] xz doesn't exist in /etc/mime.types [05:06] application/octet-stream is debatable, but loads better than text/plain [05:06] G: DistroArchSeries doesn't have a launchpad.View permission defined. [05:07] wgrant: ahhh thanks [05:07] G: Since they're all public, they need an adapter class deriving from AnonymousAuthorization (in canonical.launchpad.security) [05:07] G: There's possibly already a bug for this. [05:07] G: (they'll already appear if you're logged in, just not to anonymous users) [05:08] anyhow, it's not a dupe [05:09] if launchpad is sniffing the type, it seems to be mostly getting it right now [05:09] wgrant: apparently not [05:10] poolie: So, we can probably correct that mimetype and close the bug, then [05:11] wgrant: http://pastebin.ubuntu.com/682351/ - but I will look at existing DistroARchSeries bugs [05:11] i guess [05:11] just fix it in the db? [05:12] ironically that really may interact with the caches [05:12] because this is exactly the unusual cache of the ct changing without the content changing [05:12] so it will probably stay cached for a while [05:12] arguably there's a bug here if lp trusts the client's ct even when it shouldn't [05:13] StevenK: so how would we handle a cherrypick to something that currently comes from an egg? [05:14] wgrant: oh I get you now [05:15] wgrant: thanks for the pointer :) [05:15] poolie: We make a new egg and update the version in versions.cfg [05:15] called 0.12.0+0launchpad1 or something? [05:15] ok [05:15] StevenK: Aha, I know how to fix the Jenkins failure, and I'm just going to redisable the failing buildbot test (it was only reenabled a weekish ago) [05:16] G: Great. If you run into any issues, ask :) [05:17] wgrant: yeah, although I do like to have a big play w/ stuff before asking, because if it is a simple thing, I learn other stuffs/tidbits about the code by stuffing up :) [05:17] poolie: I hope not. :-) [05:18] poolie: Since the version of Twisted we have currently is 11.0.0 :-) [05:18] you know what i mean [05:18] We have done cherry-picks of Twisted before, I just can't remember their format [05:22] wgrant: so really, http://pastebin.ubuntu.com/682356/ is all that is needed if I understand it correctly [05:23] jelmer: Ah, worked out that bzrdir import error [05:23] jelmer: The daemon was old, from a previous test run. [05:23] jelmer: So its tree had been deleted. [05:23] G: You're missing a newline, but yup. [05:24] missing, don't you mean included by accident? [05:24] StevenK: so can i leave that with you? [05:24] i'm going to try to fix bug 643223 this afternoon [05:24] <_mup_> Bug #643223: should accept dkim based on from address and signing address belonging to the same person

< https://launchpad.net/bugs/643223 > [05:24] G: Two empty lines between classes. [05:25] wgrant: oh good point, thanks :) [05:25] I am also missing something else... [05:25] a test! [05:25] Mmm. [05:38] Hah. Old bug for test_import_bzrsvn's disablement was 541526. New one is 841556. A bit too similar... [05:39] 4 out of 14 sampledata people still work at canonical [05:39] not counting foo bar [05:40] is that good or bad? :) [05:40] i don't know [05:40] it's pretty old [05:40] not too bad [05:40] i know all but 2 of them [05:41] sampledata = stuff that rf installs onto my machine right? [05:41] yes [05:41] database/sampledata [05:41] I only saw mark as a familiar name [05:41] No, the sampledata is stuff that make schema stuff into the development database [05:41] rf installs the developer dependencies [05:42] Ah. [05:42] well, strictly, make schema not rf, yes [05:42] But poolie got what I meant :) [05:49] Hrm, today's Google Doodle is pretty awesome. [05:49] I don't know, I haven't been impressed by Google's Doodle's for a while [05:55] i had no idea he was Parsi [05:56] Neither did I :) [06:17] hmmm think I may be able to put another bug in the 'fixed' basket [06:23] stevenk, wgrant, in a test, i need a user account with multiple email addresses in different domains [06:23] what's the tasteful way to get this? [06:23] makePerson() [06:23] makeEmailAddress() [06:23] makeEmailAddress() [06:23] makeEmailAddress() [06:23] one at canonical.com one at ubuntu.com in makePerson? [06:23] on TestCaseWithFactory? [06:23] poolie: yeah, there is another test like that, that I was reading [06:24] poolie: self.factory.makePerson() ... [06:24] thanks [06:24] am i right that in general you prefer tests to always make the person (or whatever) rather than relying on the sample data? [06:26] poolie: Yes. [06:26] poolie: It is somewhat slow, but means we're not relying on fragile, rotten sampledata. [06:26] Which is largely invalid in great parts. [06:30] I'd like to remove most sampledatsa [06:30] s/sa/a/ === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 258 - 0:[########*** stack smashing detected ***: ./lp terminated [06:31] 258 :( [06:32] What is the most recent? [06:33] Bug #841556 [06:33] <_mup_> Bug #841556: test_import_cvs, test_import_bzrsvn and test_import_subversion disabled < https://launchpad.net/bugs/841556 > [06:36] wgrant: I got it! http://bazaar.launchpad.net/~dev-nigelj/launchpad/bug-674854/revision/13863 allows me to do: http://pastebin.ubuntu.com/682386/ [06:36] wgrant: thanks massively for your help [06:40] poolie: This cherrypick is not so easy, since the diff from trac won't apply at all to 11.0.0 [06:46] my patch for 721166 passed an ec2 test [06:46] bug 721166 [06:46] <_mup_> Bug #721166: Tests sometimes fail on EC2 due to _LockWarner garbage

< https://launchpad.net/bugs/721166 > [06:46] should i land it? [06:47] i think the tests can now be reenabled since lp has bzr 2.4 [06:47] Didn't wgrant just roll that back? [06:47] rolled back bzr? [06:48] I didn't roll back bzr. [06:48] I redisabled the undisabled tests. [06:48] the ones that gary changed? [06:48] they might have been different [06:50] Nah, different ones. [06:50] Did he actually end up disabling any? [06:50] I think the bzrdir import issues were due to the three I just disabled. [06:50] Leaving ancient processes around. [06:51] so my question is, really [06:51] if i land this, is there an unreasonable chance that either bzr will be downgraded or spurious failures will disrupt things? [06:51] 15 minutes ago the chance of a spurious failure disruption was probably around 0.95. [06:51] Now it's hopefully lower. [06:52] But please avoid any even slightly disruptive changes until late in the week. [06:52] We've just had about 20 failures. [06:52] ok, there's no rush [06:52] it's only a tidying-up fix [06:52] What with the three invasive bzr infrastructure changes lately, it's a bit of a mess. [06:53] oh, what were the three? [06:53] There was the 2.4 upgrade, the puller SafeBranchOpener unification, and some other codeimport/puller change, the details of which I forget. [06:54] did they break a lot of stuff? [06:54] It's not clear. [06:54] Because also around that time three tests were undisabled. [06:54] They spuriously failed in spectacular ways occasionally. [06:54] But then lots of other tests blew up in even more spectacular ways. [06:55] but I speculate that that is because of debris left by the original three broken tests. [06:55] So I've disabled them, will get buildbot cleaned up, and then hope that stuff stops failing dammit. [06:55] Otherwise I'll just revert all the bzr changes in the last two weeks and work out wth is going on. [07:00] StevenK: you could just take my patch from http://twistedmatrix.com/trac/ticket/4156#comment:7 [07:10] StevenK: How do I restart a Jenkins build? Just kill the executor and force? [07:10] * wgrant tries. [07:11] Project devel build #1,031: ABORTED in 21 min: https://lpci.wedontsleep.org/job/devel/1031/ [07:11] We may have success in 4 hours. [07:17] Project devel build #1,032: STILL FAILING in 6 min 34 sec: https://lpci.wedontsleep.org/job/devel/1032/ [07:19] Lies. [07:19] urllib2.URLError: [07:19] How unpleasant. [07:20] StevenK: You broke everything. [07:20] Seems I can't destroy the executor. [07:20] :( [07:21] Project devel build #1,033: STILL FAILING in 39 sec: https://lpci.wedontsleep.org/job/devel/1033/ [07:22] :( [07:25] ouch, that doesn't sound good [07:26] Well, the test suite has sped up by 360x. That can only be a good thing, right? :) [07:26] hehe [07:27] eek GPG tests just OOM'd in my VM [07:27] How much RAM is assigned? [07:27] and that is 2GB RAM [07:27] amd64? [07:28] There may be left over librarians and stuff eating a couple of hundred megabytes each. [07:28] amd64 with 2GiB is doable, but pushing it. [07:29] yeah, amd64 [07:29] I might download lucid-server i386 and put on that VM tbh [07:30] laptop is Core2Duo w/ 4GB [07:33] My laptop with the same specs runs it OK outside a VM, but if I want to do it in a VM i386 is better. [07:36] Is bigjools going to be around today? [07:36] There's a bunch of bugs that I want to talk to him first before touching :) [07:38] good morning [07:38] nigelb: I think he should be. [07:38] let me check. [07:39] wgrant: yeah, don't blame you for using i386 [07:41] nigelb: Looks like he should be here today. [07:42] nigelb: Yes, he will be here today. [07:42] wgrant / rvba: Thanks! [07:46] Project devel build #1,034: STILL FAILING in 44 sec: https://lpci.wedontsleep.org/job/devel/1034/ [07:48] wgrant: fast but still failing? [07:50] Yeah, the slave is broken. [07:50] Need StevenK to fix. [07:55] You do? === almaisan-away is now known as al-maisan [07:57] StevenK: I can't work out how to kill the executor. [07:57] Only the build. [07:58] would it be tasteful to add a script to lp that just processes one mail message from stdin? [07:58] at least for the sake of testing [07:59] Oh. Delete the slave. [07:59] it seems a lot easier than configuring a mailbox [07:59] poolie: It is distasteful to not have one. [07:59] StevenK: warthogs doesn't seem to have permission to do that. [07:59] or, to add a parameter to process-mail to do this (though that seems a bit hard) [07:59] Or at least I can't find a relevant button. [07:59] :) [08:01] Navigate to the slave, hit the button on the left. [08:01] https://lpci.wedontsleep.org/computer/i-225ca042/ has only four links on the left. [08:01] Back to List [08:01] Status [08:01] Build History [08:01] Load Statistics [08:05] wgrant, ok, will do [08:05] we could potentially even get the mta/mda to feed messages directly in to this [08:05] though startup time may make that suck [08:06] "may" [08:06] well [08:06] will it be worse than the current latency from running from cron? [08:06] and, will the wasted cpu matter? [08:07] i don't know how busy the machine that currently does this is, and how much mail it gets [08:07] It's about 10s of CPU time per invocation. [08:07] That's not insignificant. [08:07] true [08:07] especially if we get mail more often than every 10s during peak time [08:07]