[00:06] jelmer: i've just noticed the same thing, don't know what causs it :-( [00:06] I can reproduce it on both of my machines [00:06] i've just upgraded to oneiric [00:06] my machines are both on oneiric [00:06] strangely enough the server logs indicate that the client disconnected suddenly [00:08] ssl error? [00:08] mwhudson: yup [00:08] why do we use ssl on a db connection to localhost? :) [00:08] it isn't trying to use SSLv2, is it? [00:08] and why has it started failing now? what's changed? [00:08] well, actually, that was turned off in natty [00:09] but OpenSSL 1.0.0 in Oneiric turned off various other rarely-used bits of SSL [00:09] things like MD2 hashing [00:09] might be worth checking that [00:10] might explain why lucid hasn't any problems [00:11] cjwatson: that's an interesting thought [00:13] cjwatson: that's just libssl0.9.8? [00:16] jelmer: well, it's libssl1.0.0 now [00:16] there's only a handful of libssl0.9.8 reverse-deps left, and none that I think have anything to do with Launchpad [00:21] it seems unlikely that's the culprit [00:21] I have libssl1.0.0 1.0.0d-2ubuntu2, which was uploaded on aug 15; the breakage started at most two or three days ago [00:22] well, it could have been some dependency switching over to it (they're different sonames), but yes, two or three days ago does make that a bit unlikely [00:25] hmm [00:26] I'll have a closer look tomorrow, thanks for the hints [00:26] wallyworld_: if you do stumble upon a solution.. please let me know :) [00:26] jelmer: Can you explain https://code.launchpad.net/~loggerhead-team/loggerhead/1.18/+merge/74532 ? It's full of conflict markers. [00:26] jelmer: will do. i'm currently looking at something else though [00:29] StevenK: argh, fail. I'll set it back to wip for now [00:30] the trunk *packaging* branch seemed to merge 1.18 just fine for some reason, looks like 1.18 and trunk don't :( [00:43] jelmer: i replaced host with hostnossl in pg_hba.conf and it works for now [00:44] Odd, it's working fine for me. [00:45] But it's in a container. [00:45] wgrant: i think lucid is ok [00:45] Container is up to date, host is not... maybe will upgrade the host too. [00:45] No, this is an oneiric container. [00:45] something seems to have changed wrt ssl that has broken things, so if you upgrade, be careful [00:46] gah. my "fix" didn't work a second time [00:47] * wgrant upgrades the host. [01:04] * StevenK stares at Thunderbird [01:04] "Canonical has 21524 new messages." [01:04] OMGWTFBBQ?! [01:16] StevenK: that's in the staging mailbox? [01:17] wallyworld_: No, my Canonical mailbox [01:17] oh. that's a shitload of messages then [01:18] It was telling lies, but it was still a little shocking [01:27] 21.5k new messages, ouch === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 253 - 0:[########]:256 [02:28] Project db-devel build #849: FAILURE in 4 hr 12 min: https://lpci.wedontsleep.org/job/db-devel/849/ [02:29] Erk [02:30] Ah. [02:30] legit failure. [02:30] Merge issue. [02:30] * wgrant enfixorates. [04:20] Oh. I may have gotten a branch reviewed but forgotten to ask to land [04:20] nigelb: Which? [04:20] https://code.launchpad.net/~nigelbabu/launchpad/font-fixes-787798/+merge/74492 [04:21] I wonder if that's totally pointless to run through ec2 [04:22] It is. [04:22] o/ nigel, stevenk [04:22] Morning poolie! [04:22] O hai [04:23] Oooh, the Ubuntu font thing landed. It looks good. [04:23] And while we're at it: hi Nigel, hi antipodeans! [04:23] haha [04:23] Yeah, we deployed early AU morning [04:24] \o/ [04:25] If I may interrupt briefly… is anyone willing to review this soyuzzy branch? Julian said he would yesterday but evidently he didn't get around to it, and I've got other work building on it: https://code.launchpad.net/~jtv/launchpad/bug-832647/+merge/74380 [04:25] % df -h /home | tail -n 1 [04:25] /dev/mapper/sys-home 46G 42G 2.1G 96% /home [04:25] Hmmmm [04:26] what's /dev/mapper? lvm? [04:27] Yeah, LVM [04:27] Well, strictly, it's device-mapper, so could be LVM or something else than makes use it [04:28] StevenK: you're almost done! [04:28] Hah [04:29] I still have 75G unallocated in the VG, so I could just grow /home ... [04:32] How hard is bug 88545. Is it even possible to do for someone without acces to the db? [04:32] <_mup_> Bug #88545: Abolish the "statusexplanation" database field

< https://launchpad.net/bugs/88545 > [04:34] It's a DB patch [04:34] nigelb: you need to make a patch that changes the db but you don't need access to the db to write it [04:34] But it may take postgres more than 2.5 seconds to perform ... [04:34] probably the first thing is to just grep for statusexplanation and see if anything uses it at all [04:34] eg to remove it from the activity log [04:34] Ah [04:35] do I need db-devel setup? [04:35] (that seems to be the branch where all db stuff happens) [04:36] So to remove it from the activity log, no, that can probably just land. [04:36] You want to make sure the model and interface no longer reference it [04:36] And then you write *just* a db patch to ALTER TABLE DROP COLUMN [04:36] Okay :) [04:37] Graduating to the bugs not marked easy or trivial :D [04:37] The drop column might perform poorly -- I suggest you talk to stub when he surfaces [04:37] Yeah, I think so as well. [04:37] But the first two steps should be easy enough [04:37] i think you get a badge for fixing an mpt bug too :) [04:38] if you haven't already [04:38] * StevenK fixed a few at the Thunderdome [04:38] 'a moment ago' is my fault [04:38] i think i have too [04:39] I've fixed way too many mpt bugs already [04:39] StevenK: column dropping is cheap. [04:39] StevenK: The rows don't get rewritten, the column just gets ignored. [04:39] The next time the row moves, it will be shrunk. [04:40] Does VACUUM clean it up? [04:40] Possibly not entirely. [04:40] But it's not important. [04:41] It only takes a bit of disk space, and it's not going to be a truly massive column. [04:41] It's still used, so that has to go. [04:42] Yes. [04:43] Still want a reviewer for a soyuzzy branch! Blocking me a little and reviewer didn't get around to me yesterday: https://code.launchpad.net/~jtv/launchpad/bug-832647/+merge/74380 [04:45] jtv: Interesting tactic to teach the dominator about deletion... [04:45] (looking) [04:46] wgrant: "interesting" as in "cleverly unexpected," or "interesting" as in "oh my God what were you thinking"? :-) [04:46] Thanks btw. [04:46] A combination. [04:46] In the Ubuntu case I'd prefer a crash over a deletion. [04:47] Crashing shouldn't be hard. [04:48] Anyway, that's for later: I left Ubuntu domination in a state where you don't get deletions. [04:49] I'd prefer it was for now. Domination has always been very fragile -- I've spent today diagnosing issues surrounding it, with a production incident caused in part by a bad refactoring of the dominator that I made and fixed last year. [04:50] With a big change like this, I'd really prefer you stick an assertion in there so breakage doesn't go unnoticed. [04:51] What would I assert though? distro_name != 'ubuntu' or pubs[0].sourcepackagerelease.version == pubs[0].sourcepackagerelease.version? [04:52] I don't know. But gina and archivepublisher currently use dominator to do different things, so they should probably run it in different modes. [04:52] The dominator should never delete anything in a Soyuz-native archive. [04:52] Only for gina. [04:52] It will cease to be Ubuntu-specific this year. [04:53] Wait, now I'm completely confused. What are you saying is currently Ubuntu-specific? [04:53] Not gina, obviously, [04:53] and not the dominator, obviously, [04:53] so what will cease to be Ubuntu-specific? [04:53] When I said "In the Ubuntu case", I really meant "In the Soyuz-native case" [04:53] Currently Soyuz-native archives are Ubuntu-specific, but they will cease to be soon. [04:54] Okay, to prevent further confusion, could you re-state with that mistake fixed? [04:54] Gina will cease to be specific to Soyuz-native archives this year? [04:55] gina is by definition not used for Soyuz-native archives. [04:55] So what will cease to be specific to Soyuz-native archives this year? [04:55] Nothing. Soyuz-native archives will cease to be specific *to Ubuntu*. [04:55] I said before that stuff was specific to Ubuntu. [04:55] But I really meant specific to Soyuz-native archives. [04:56] In particular, the dominator should never call requestDeletion on a publication in a Soyuz-native archive. [04:56] It should instead crash, as that case doesn't make sense. [04:58] Well the algorithm I've got here (the part that gina bypasses, so that's the "different mode" you referred to above) is such that the deletion case just can't happen. It's the what-do-we-do-now answer—the one you wanted, I should add—for the newly possible case in gina only. [04:58] How we may extend it later to make that case possible for the publisher's domination is a later concern. [04:58] Sure, it shouldn't be able to happen. [04:58] But I want the code to ensure that it can't. [04:59] Because nature finds a way. [04:59] We've been bitten before by things like supersede() working on a deleted publication. Other code breaks, calls methods in bad ways, and they do things that nobody ever expected. [04:59] Okay, how would the assertion check for a Soyuz-native archive? [05:00] dominatePackage will need to know in what mode it is being called. [05:00] By _dominatePublications or that new thing. [05:01] Because it should never call requestDeletion when it's called by _dominatePublications. [05:01] No, I don't know what to call the argument :( [05:02] I don't think it makes any sense to pass a mode argument just to enable an assertion that, essentially, the caller also passed the expected value for another argument. [05:03] I guess. [05:03] anyway. dominate_imported_source_packages looks like it's only going to dominate sources that are still named in the source archive's indices. [05:03] So it won't actually catch deletions, will it? [05:03] Because they'll no longer be in the indices at all. [05:03] That's for my follow-up branch. [05:03] Ah. [05:04] I've already got most of the code here; it works out to be quite elegant. [05:04] Indeed, this has turned out pretty well, I think. [05:04] Especially in the way it lets us handle migration. [05:04] Yes. So I guess the first run will sort out everything that's not deleted... I think that looks OK. [05:05] The new code iterates over all package names that are published in the series/archive/pocket, and then get()s the list from gina's src_map. [05:06] Ah. I was thinking you'd have to union, but of course this is done after everything is imported. [05:06] *In the transitional code*, if it's not in there, it finds the latest version (reusing otherwise useful bits of the dominator) and passes that as live_versions. [05:06] So the DB set is fine, indeed. [05:06] Yup. [05:06] *Once transition is complete*, I'll remove that code and then the get() will have [] as a default value. [05:07] The really great thing about it is that it requires no code of any real complexity or intimacy, except stuff from the dominator that we can reuse. Some of it is private, but who cares for explicitly temporary code? [05:07] Yep. [05:08] Oh, RARGH [05:08] nigelb: Still here? [05:08] I would appreciate a comment in dominatePackage stating that deletion should never happen in native domination, as the live publication is always first. But you have me convinced that the assertion is not required. [05:11] Thank you for forgetting my session totally, Firefox [05:12] wgrant: I agree with the idea of a comment, but this policy choice falls above dominatePackage's pay grade. It should be in _dominatePublications, where the choice is made that leads to this. [05:13] I know it's not really appropriate for dominatePackage, but with a conventional understanding of domination the code makes no sense. [05:20] wgrant: I'm in the process of writing docstrings, with a comment in _dominatePublications pointing out how the mechanism enforces the policy. [05:21] jtv: Thanks. [05:22] Approved. [05:22] \o/ [05:22] Thanks [05:22] Now if only ec2 would work for me. Perhaps I should give it another try. [05:23] Worked fine for me this morning. [05:24] Still confused :-/ [05:24] But Eventbug helped a little [05:31] StevenK: yeah [05:31] nigelb: Compounded by testfix! [05:31] But your branch has landed [05:31] haha [05:31] I have great luck! [05:32] \o/ [05:32] * StevenK ponders asking for buildbot to be set on fire. [05:37] StevenK: need help burning it? :D [05:38] Haha [05:38] I need help with JS, I'm so confused [05:40] StevenK: i need to go to soccer soon, but can i help with js? [05:41] wallyworld_: I'm trying to figure out what JS is fired when I hit a link [05:41] StevenK: normally you would register an onclick handler [05:41] unsubscribe from this bug [05:41] No onclick [05:42] StevenK: there is one set up - but it's done in js whe nthe page loads [05:42] the href="#" means that an onclick wil be used [05:42] But doesn't that mean there's no fallback in case of disabled JS? [05:43] probably, but we require js for lp now [05:43] cewrapper.fire(Event.getEvent(e, el, compat || false === facade)); [05:43] * StevenK blinks [05:43] StevenK: try looking in bugtask_index.js or bug_subscription_portlet.js [05:44] i think one or both of those have methods which run in the onload callback to set up the links [05:45] lib/lp/bugs/javascript/subscription.js looks very related [05:45] But I have no idea how to find the onclick handler function for the link so I can trace it [05:45] StevenK: it's bug_subscription_portlet.js. see it's make_link() method to set the attributes on the link as you posted above [05:46] nigelb: the link does have a fallback - the js sets the href="#" [05:46] StevenK: let me have a quick look [05:46] wallyworld_: Ah! :) [05:47] StevenK: search for link.on('click' [05:47] there's a few of those for the mute link, the subscribe link etc [05:47] wallyworld_: The page I'm on is https://bugs.launchpad.dev/product-name-989062/+bug/16/+subscriptions [05:47] <_mup_> Bug #16: "Swedish" and "Swedish (Sweden)" should be the same language < https://launchpad.net/bugs/16 > [05:48] * wallyworld_ looks [05:48] I know that doesn't help you much, but it isn't the bug page [05:48] Oh, that's not the subscriptions portlet. [05:48] Exactly [05:49] And Firebug's script tab isn't being very handy about pointing out where the JS is hiding [05:50] StevenK: i don't think you would normally get to that page except by url hacking [05:50] but it is the subscriptions portlet i think, put not rendered in a portlet [05:50] Huh? I followed a link to get to that page! [05:51] The "Edit bug mail" link [05:51] StevenK: oh ok. anyway see the bug-subsctipion-list.pt [05:52] it loads the bug_subscription_list.js [05:52] which is the same js as used for the subscription portlet [05:52] StevenK: i have to run to take the kid to soccer but will check back in 30 minutes or so [06:03] Oh god, all of the JS is in launchpad.js, isn't it [06:04] All 100,000 lines of it [06:04] isn't that a build product? [06:04] StevenK: yup [06:04] Yes, but it's the JS the browser sees [06:04] Whereas the JS we edit is split out [06:04] Its fun using firebug. [06:23] StevenK: found it yet? :) [06:29] wgrant / StevenK: Do you both have HE tunnels? [06:31] We use AARNet's tunnel broker. [06:31] It's a little closer :) [06:36] heh [06:40] I'm quite happy with it [06:40] * ajmitch wonders when lp & *.ubuntu.com can be accessible on v6 [06:41] StevenK: how's the js stuff? [06:41] wallyworld_: Crappy [06:41] Giving up for today [06:41] need any more help? [06:41] ok [06:41] wallyworld_: I might grab you inappropiately after the stand-up [06:41] oooh. promises, promises [06:41] BWAHAHA [06:42] Should I or should I not screenshot. [06:50] nigelb: the way I see it, this could be your retirement money. And then again, it could be your reason for not reaching retirement age. [06:51] jtv: I would much rather prefer using it in a presentation. So, I'm leaning to the second option. [06:52] “Not screenshot”? [06:52] Screenshot and use in a presentation [06:52] wgrant: do you have a minute to clear up a confusion in the ipv6 wiki page? [06:53] It says "gksudo gedit /etc/networking/interfaces", in lucid its /etc/network/interfaces. On oneiric do you have networking instead? [06:54] IIRC it's always been /etc/networking/interfaces [06:54] (and by "always" I mean "going back to Debian a decade ago"—I don't know much more than that really) [06:54] It's always been /etc/network/interfaces [06:55] As long as I've been using Debian, which is like 2002. [06:55] Ah. Tab completion has spoiled me. [06:55] And somehow admins who don't seem to mind this keep refusing to set up tab password completion. It's not fair. [06:55] Heh [06:56] ok, so the wiki is lying. [06:56] BTW my having been using Debian for longer than wgrant comes as a bit of a shock. [06:56] My using Debian for longer than wgrant can walk, that I would have believed. But this… [06:56] well, he should be old enough to read before he uses a computer... [06:57] Good point. [06:58] I sadly used Windows until 2001 :( [06:58] No buffer space available? [06:58] GAH. No ipv6 yet for me. [06:59] wgrant: I used Windows until 2007. Windows Vista for a year too (yeah, *stab* *stab* *stab*) [07:04] Lunch time! Laters folks. [07:13] Hmm, no stub yet :( [07:16] Morning stub. [07:16] Morning [07:17] stub: We snuck a librarian deployment through without downtime earlier, so everywhere is 13891 except germanium's poppy and cocoplum. [07:17] Hopefully that is all the fixes we need. [07:18] It is all the fixes we know we need in any way :-) [07:18] Right. [07:19] So if mthaddon has time when he gets here or spm is free, we can kick the tires. [07:20] stub: My zopeless destruction branches get rejected by the devel database/schema check :( [07:20] With luck you can land it on devel later today. Tests pass? [07:20] Yup, all three went through ec2 overnight. [07:21] Are we going to lift the restriction? [07:21] Since otherwise we're going to be doing a lot of manual merging. [07:21] wgrant: I just realized we never did make Gina create Published publication records. Still all Pending. So need to change the code for that as well, _and_ update the database. [07:21] I like having it as a safety net, but I don't see the point of having be so vigorously enforced. [07:22] jtv: We do, but it's not critical. [07:22] jtv: Since your new dominator method finds everything that's active. [07:22] Not just published. [07:22] wgrant: errrr [07:22] I stuck to the logic that was already there, which looked for published. [07:23] + self._composeActiveSourcePubsCondition(distroseries, pocket)) [07:23] Is that active, or published? [07:23] It's published. [07:23] Heh. [07:23] The dominator tends to say "active" when it means "published." :( [07:24] But let me just double-check, because we had the confusion in gina before. [07:24] stub: So, I guess we should actually try it tonight... [07:24] Yup, published. Not active. [07:24] wgrant: now if I can sucker hloeung into doing it [07:25] * hloeung logs off... right.... now.... [07:28] StevenK: Hi, I'd like to ask you a question about the creator field of spph. [07:29] It was introduced by a branch you created to fix bug #684101. [07:29] <_mup_> Bug #684101: Add an ancestor column to SPPH

< https://launchpad.net/bugs/684101 > [07:29] rvba: It and ancestor were never used. [07:30] Indeed, Julian an I took a look at the db and it's None. (besides, copyTo sets it to None) [07:31] wgrant: StevenK I'd like to use it for real to track copies of spph. Any objection? [07:32] That was the intention of creator, so do it! [07:32] It was added alongside ancestor mostly because it was convenient. [07:32] And ancestor then became redundant; we examine changelogs instead. [07:32] Okay great, this will save me a db patch! [07:33] wgrant: Thanks. [07:33] rvba: Not that that is a problem. [07:33] stub: wgrant: landing schema changes on devel? I'd suggest needing a [schema] tag in the commit, but perhaps that wouldn't actually help. [07:33] lifeless: Possibly, yes. [07:33] lifeless: If you're not watching #-ops, we're about to do the first test. [07:33] I'm not here :) [07:34] safety net off, free falling :) [07:35] wgrant: someone should tweet :) [07:35] Once we're confirmed that it's going ahead, yep. [07:35] lifeless: something like that, yer. Although I hate overloading the commit message with metadata. [07:37] will need a pqm patch if we want it, but htats not as scary as some folk think :) [07:38] good morning [07:42] Yippie, build fixed! [07:42] Project db-devel build #850: FIXED in 4 hr 36 min: https://lpci.wedontsleep.org/job/db-devel/850/ === rvba changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: rvba* (jtv) | Critical bugs: 253 - 0:[########]:256 [07:45] First day as OCR, allenap is off today so jtv has kindly accepted to be my mentor today. [07:46] “Soft target. Fire away!” [07:46] :) [07:50] jtv: That is a very long XXX comment! [07:51] jtv: Are you going to land this before we do the code+data fixes for Pending->Published? [07:52] wgrant: probably, unless it turns out to be inconvenient w.r.t. how we update the legacy data. [07:53] As long as Gina doesn't get to observe the Pending→Published change in an unnatural order, it shouldn't make much difference AFAICS. [07:53] Indeed. [07:53] About the worst I can imagine for that scenario is intermediate, but more-or-less-accurate, supersededby links. [07:54] jtv: Why are you using _sortPackages instead of sorted(..., cmp=generalization.compare), as you did in dominatePackage? [07:54] You should only have SPPHs for a single name, so _sortPackages isn't needed. [07:54] Just because it gets a little less intimate with the data. [07:55] Matter of taste, really, no more. [07:55] k [07:56] Approvalated. [07:56] Great, thanks. We're really going through them at a clip now. [07:56] Which is good, because I once again gave Julian a "done by the end of this week" estimate. [07:57] Hmm I just realized though: with these changes, the new source file I added to gina ought to be called dominate.py, not retire.py [07:58] Probably. [07:59] And done. [08:22] * mpt awards nigelb his "fixed an MPT bug" badge: (╯°^°)╯︵{FAMPTB} [08:25] heh === almaisan-away is now known as al-maisan [08:31] haha [08:31] I should get that on a t-shirt. [08:31] Next UDS I attend, I'll do that :D [08:34] rvba: welcome to reviewing :) [08:35] G: ;) [08:35] here have a look at this patch that removes all the code.... ;) [08:38] G: That sounds like StevenK's branches :P [08:40] stub: Hi [08:40] nigelb: haha sounds about right :) [08:41] stub: I was asked to run bug 88545 by you. Specifically the bit that requires a db patch [08:41] <_mup_> Bug #88545: Abolish the "statusexplanation" database field

< https://launchpad.net/bugs/88545 > [08:42] nigelb: I can't look right now - deployment stuff underway. Should be able to check it out within the hour though. [08:42] stub: sounds good [08:53] [6~[6~[6~[6~[5~/wg 62 [08:53] GAH [08:53] heh [09:14] GAH. Bad thing about working from home - telemarketeers knocking on the door. [09:15] Telemarketers... on the door? [09:15] Well, wrong word. [09:15] wgrant: I was just going to make that point [09:15] The door-to-door salesmen [09:15] but it was pretty obvious that we all knew what the other Nigel meant :) [09:15] parasites? [09:16] I guess you could call them that. [09:19] one advantage of living up a 100m driveway and all that, about the only door-to-door thing we get is various churches/religous ones, and the occasional one that does things like door-to-door sales of aerial photography etc [09:24] Same here! [09:25] last time I had some religious dudes show up, I squirted them with "holy water" and brandished garlic [09:26] ttp://hawkersnotice.com/ [09:27] bigjools: heh [09:27] lifeless: Its not linked! thedoghousediaries.com/?p=3003 [09:28] Oooh,that is good stuff. [09:29] Amazon has "11.6 seconds mean time between deployments"... what in the world. [09:29] lots of focused services [09:30] Is that where the service oriented architecture is leading Launchpad to? [09:30] yes [09:30] excellent! [09:31] The goal is that all commits to trunks are deployed on their own, without batching, and that unrelated things are separate services with narrow contracts [09:32] Or it just means serialized deployments to lots and lots of hosts... [09:32] unrelated things? [09:33] nigelb: librarian vs codehosting vs group management vs build farm vs ... [09:34] ahhh, right [09:35] How does lp deploy now? I know its batched etc. But is it a click to deploy? [09:35] not quite but close [09:38] Any reviewers in the house? https://code.launchpad.net/~jtv/launchpad/bug-844577/+merge/74568 ← bigjools maybe, since you didn't get around to my bigger branch yesterday? [09:39] The reason I ask is, would making each commit deployed on their own cause more work than now? [09:39] jtv: sorry, gotta sort out a prod issue [09:39] Ah of course, sorry, [09:39] —kept that in a different context [09:40] Anyone else? https://code.launchpad.net/~jtv/launchpad/bug-844577/+merge/74568 [09:41] nigelb: it always will [09:41]