[00:00] wgrant: Did you want a review, or you're still fighting tests? [00:00] (Like I am.) [00:02] I'm fighting a branch scan timeout [00:04] Glad to hear it's not just me. [00:04] Er, I mean, that's terrible. [00:08] StevenK: https://code.launchpad.net/~wgrant/launchpad/bug-1098170/+merge/142816 [00:14] wgrant: Looks good, r=me [00:14] Thanks [00:29] wgrant: https://code.launchpad.net/~stevenk/launchpad/no-count-distribution-ppas/+merge/142818 === slank_away is now known as slank [00:32] StevenK: r=me [00:33] wgrant: Oh, so IDistribution.getAllPPAs().is_empty() is fine? [00:34] StevenK: If it works, why wouldn't it be? [00:34] wgrant: It works, I'm concerned it's going to perform terribly. [00:35] is_empty() is very different from count() == 0 [00:35] Because is_empty will stop as soon as it finds a row [00:35] So an index on archive(distribution, purpose) will have it satisfied in microseconds [00:36] "archive__distribution__purpose__key" UNIQUE, btree (distribution, purpose) WHERE purpose = ANY (ARRAY[1, 4]) [00:36] Note that that's not actually useful [00:37] That index, or the property? [00:37] The index [00:37] It's partial over (PRIMARY, PARTNER) [00:37] You may want to create a new index [00:37] Mmmm [00:37] But this will be strictly faster than what was there before, and trivially fast for Ubuntu [00:37] For other distros it will be slower [00:39] (simply because for ubuntu/+ppas it has to find any one row matching distribution=1 AND purpose=2, for which it has to search at most 67 rows, because there's only 66 archive rows that *aren't* Ubuntu PPAs) [00:40] StevenK: Oh [00:41] I missed something in that review :( [00:45] Oh? [00:50] Hah, test failure [00:50] assertContentEqual ? [00:52] Oh, I only sorted one end [00:52] Oops [00:52] StevenK: But the thing I missed was that you ended your commit message in a preposition. [00:53] wgrant: The description, rather than the commit text? [00:53] assertThat(... MatchesSetwise) might be your friend [00:54] lifeless: assertContentEqual is shorthand for that [00:54] wgrant: then sorting shouldn't be needed [00:54] wgrant: isn't it shorthand for MatchesListwise ? [00:54] Yes, but I didn't use assertContentEqual :) [00:54] Because I copied it from another test [00:55] def assertContentEqual(self, iter1, iter2): [00:55] """Assert that 'iter1' has the same content as 'iter2'.""" [00:55] self.assertThat(iter1, MatchesSetwise(*(map(Equals, iter2)))) [00:55] Bad wgrant, no cookie. [00:55] wgrant: well then :) [01:00] wgrant: Are you landing a testfix, or shall I? [01:01] I am [02:08] StevenK: No +queue timeouts yesterday [02:08] And only three soft [02:09] The remaining slow queries are because of partner and the COUNT(*), but they're only 700-900ms each [02:15] nice [02:26] More problems solved by the destruction of PARTNER [02:33] All problems are solved by the destruction of PARTNER === slank is now known as slank_away [03:22] * StevenK stabs this branch, gives up and casts a wide net for anything that wants IEmailAddressSet. [03:23] Or I just call into traceback from IEmailAddressSet.new and toss a ValueError if the call trace doesn't contain LoginToken [03:27] wgrant: So, due to ripping it out of getOrCreateOpenIDIdentifier, it looks like the person browser code only create a LoginToken [03:27] The LoginToken code will cope if the EmailAddress exists or doesn't. [03:34] Hmm [03:36] StevenK: Ah, so it does [03:37] Which would explain why I couldn't find it. [03:37] wgrant: So I can put up this +10/-17 branch, but it's all tidy-up [03:40] Oh [03:40] Person.unvalidatedemails is actually calculated from the logintokens [03:40] Intriguing [03:40] So you're right, it's already all good [03:40] StevenK: Might as well put it up [03:41] And I can't see any errant calls to IEmailAddressSet.new, either [03:42] wgrant: So two bits of QA and we should deploy? [03:43] I'm testing the OpenID thing atm [03:52] wgrant: https://code.launchpad.net/~stevenk/launchpad/random-logintoken-cleanup/+merge/142827 [03:53] StevenK: That looks like an ideal candidate for a self review [03:54] Pfft [07:03] wgrant: Did you not close bugs from the NDT? [07:03] wgrant: And do we want to find the '' OpenID identifier in the DB and shoot it? [07:06] Ah, no, got distracted [07:06] * wgrant closes [07:06] And no, we don't want to dispose of that yet [07:06] There's a lot more cleanup we need to do next week [07:07] wgrant: I just did the closing [07:07] StevenK: Um [07:07] You reset the mailing list one to Confirmed [07:07] Oh, whoops [07:07] I think that was a miss-click :-( [08:51] good morning === yofel_ is now known as yofel === almaisan-away is now known as al-maisan [09:55] StevenK: https://code.launchpad.net/~wgrant/launchpad/expire-some-p3as/+merge/142857 [10:03] wgrant: That is pretty hideous, yes. [10:03] wgrant: Your Brilliant Plan[tm] is replace that horridness with Archive.expirable which defaults to True, I guess? [10:05] I'd say so [10:05] Somewhere on +admin, I suppose [10:05] wgrant: r=me, hopefully it's short-lived. [10:06] Thanks [10:06] Indeed [10:06] It won't be :) [10:20] wgrant: :-( === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === slank_away is now known as slank === slank is now known as slank_away === slank_away is now known as slank === salgado is now known as salgado-lunch === salgado-lunch is now known as salgado === al-maisan is now known as almaisan-away [19:24] is anyone around? === Ursinha_ is now known as Ursinha [19:49] dobey: yup [19:50] https://launchpadlibrarian.net/128211802/buildlog.txt.gz :( [19:50] (yes still getting this, and still no idea why) [19:51] dobey: it's never simple with you is it :p [19:52] dobey: when was the last time you got this ? [19:52] today; that build was from a few hours ago [19:53] it happens whenever i try to rebuild lp:ubuntu/ubuntuone-client via a source package recipe [19:53] but building the same recipe locally works fine (creates the source package) [19:55] deryck: any ideas? [19:55] looking up..... [19:55] deryck: thanks [19:58] so I'm not very knowledgeable about builds. The "Most recent Ubuntu Raring version: MISSING" repeated looks suspect to me. [19:59] but maybe that's normal noise. [19:59] dobey, is it trying to pull in some dep that isn't available in Raring perhaps? (just guessing, really.) [19:59] Other than my guessing, I'd say file a bug and get wgrant or StevenK to take a look when they're online. [20:00] deryck: no; that's just a normal message from bzr bd [20:00] deryck: the main issue is the pristine-tar failing [20:00] the traceback and those MISSING messages are just noise really [20:00] mgz: you gone> [20:00] yeah, it's not a very helpful Traceback. [20:01] deryck: right, the traceback is just restating that pristine-tar failed [20:01] I'd guess we'll need someone to look through builder logs to get more info. [20:02] I'm assuming we have something more detailed than this, but maybe not. [20:04] yeah, i don't have any more info really. it's been happening since i set this recipe up; all my other recipes that just re-build lp:ubuntu/$something are working fine though [20:05] it's only this one for ubuntuone-client that's failing [20:05] hmmmm [20:06] dobey, I'd say file a bug or question, and let czajkowski poke wgrant or StevenK about it. [20:06] and i've tried to build the recipe on quantal and raring at various points over the past couple months, and it's worked fine locally both times [20:06] ok [20:06] sorry, wish I could be more help. [20:07] can you poke at the logs now and see if anything is there? [20:07] or do i need to find someone in ops to do that? [20:14] dobey, ask someone in ops. I don't know where the logs are, so they can probably help you quicker. [20:15] ok === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [21:10] czajkowski: mostly/nearly [21:16] mgz: dobey was having some issues above but I think he's gonna report a bug and get it looked at [21:17] and I don't have any particular clever ideas about dobey's recipe problem, though I wonder if his successfuly local build used a newer/bugfreer version of bzr-builddeb than the builders do [21:18] reporting a bug is the right thing, as I think the buildlog is basically the same as his failure from the other week [21:18] mgz: it's dailydeb, though pristine-tar is actually what's failing [21:18] mgz: would that relate to the RT that we mentioned earlier on [21:18] mgz: it is exactly the same as the previous failure, yeah [21:19] right, I guess my best bet would be on either pristine-tar or builddeb being too ancient on the builder [21:19] mgz: what version of pristine-tar and dailydeb do the builders have, where the recipes get built? [21:20] actually, pristine-tar [21:21] the older version makes some sense, if it's not using the ustar format for the tars it builds [21:21] and newer version might [21:22] dobey: log says "builder 0.7.2dev" and my guess is pristine-tar would be the one from the archive [21:23] ah, this version line is useful: [21:23] Buildd toolchain package versions: launchpad-buildd_113~0.IS.08.04 python-lpbuildd_113~0.IS.08.04 bzr-builder_0.7.2+bzr156-0ubuntu1~1.IS.8.04 bzr_2.4.0-0ubuntu2~11.IS.8.04. [21:24] mgz: right, but which version of Ubuntu is it running on? i'm guessing there's a big difference between what's in raring, precise, or lucid [21:25] right, lucid I think, but that's not actually mentioned [21:25] oh, no, precise [21:25] that's actually reasonable. [21:26] (well, the environment is precise, the underlying machine may me more ancient) [21:27] ok, let me try the recipe on precise then [21:29] i just realized that u1-client does have some "too long" filenames, and we have to use tar-ustar with automake to get a proper tarball. older pristine-tar might fail there [21:38] hmm [21:38] ok, this is weird [21:38] on precise it's not even doing the "Reconstructing pristine tarball" bit for some reason [21:42] hrmm, but it runs ok on quantal and raring for me, but on lp it fails on quantal. so i wonder if the dailydeb command is actually being run while chrooted, or what === gary_poster is now known as gary_poster|away [23:05] dobey: The builds run on hardy [23:05] dobey: With various newer packages [23:08] wgrant: is pristine-tar one of those "newer packages?" i suspect not? [23:09] It's certainly been backported in the past [23:10] pristine-tar | 1.11ubuntu1~0.IS.8.04 | hardy-cat-buildd | source, amd64, i386 [23:10] Probably that [23:10] 1.20~0.IS.10.04 is in lucid-cat [23:11] hardy itself had 0.8, and 1.00~hardy1 in -backports [23:11] Yeah [23:11] There have been changes relatively recent [23:11] eg. to cope with a bz2 change, IIRC [23:11] could we get a newer version in? [23:11] Hahaha [23:11] We have an old old RT about upgrading the builders [23:11] It's been idle for maybe 18 months now [23:12] or just upgrade them to precise [23:12] :) [23:14] how does dailydeb create the tarball exactly? would be nice to see what command line it's using to do that, but it's not in the build log :-/ [23:17] I have no idea. [23:17] You could check the source. [23:29] wgrant: is there some way i can test this on one of the builders more easily than just watching my build fail again and again? or get access to the buildd ppa so i can set up a vm/chroot to test in? [23:31] dobey: It's not a PPA, but you can get at hardy-cat-buildd from the DC (e.g. chinstrap) - archive.admin.canonical.com [23:31] dobey: So you can just download the relevant bits by hand or whatever [23:32] (The output I posted earlier was from a madison-lite instance on chinstrap configured to look at a.a.c.c, without using any special privileges beyond having a chinstrap account) [23:33] ok [23:33] I expect that in general IS would prefer details of what's in CAT not to be shared around [23:33] of course [23:33] Not that I know the details, just seems like a safe assumptin [23:34] +o [23:34] But handy for debugging this kind of thing [23:36] thanks