[00:03] wgrant: The librarian GC is hideous [00:04] Surely not. [00:04] But WTF are you doing in there? [00:04] Ripping out staticdiff? [00:05] No, it errors since it uses introspection and no longer has access to openidrpconfig [00:05] OpenIDRPConfig has an LFA? [00:05] Oh, the logo? [00:06] So, just leave the permission. [00:06] Yeah, the logo [00:06] It must hold it until we drop the FK, which I will do with the other 30. [00:13] wgrant: http://pastebin.ubuntu.com/682968/ [00:15] StevenK: Interesting, jelmer had the same thing, but it works for stub and I. [00:15] host localhost [00:17] .1 and ::1 [00:18] Open up pg_hba.conf, duplicate the 127.0.0.1/32 trust line with ::1/128 [00:18] Reload postgres, and see if that fixes it. [00:20] wgrant: It does, yes. [00:22] * wgrant fixes launchpad-database-setup and mails the list. [00:23] StevenK: +host all all ::1/128 trust [00:23] ? [00:24] "host all all ::1/128 trust" is what I added, yes [00:25] Hmmm. [00:25] Interesting. [00:25] My postgres isn't listening on v6. [00:25] Possibly because the container I was testing in isn't properly bridged, so it only has a link-local address. [00:26] But detecting using that sounds pretty hideous. [00:27] I know glibc did that sort of check to prevent DNS hangs... but postgres? [00:29] StevenK: Is your listen_addresses setting the default? (commented out or 'localhost') [00:31] wgrant: It's commented out [00:31] StevenK: Can I have your /etc/hosts? And is this natty? [00:33] wgrant: Yes, and http://pastebin.ubuntu.com/682984/ [00:33] That looks either upgraded or mangled. [00:33] Hah, mangled. [00:34] I suspect line 6 is the difference. localhost isn't there on my machines. [00:34] Anyway, I will fix launchpad-database-setup. [00:34] Thanks. [00:37] Now the last failure is in xx-person-edit [00:37] Which now fails since it now prints the OpenID warning everytime [01:02] StevenK: Jenkins is still happy! [01:06] Gasp! [01:11] wgrant: http://pastebin.ubuntu.com/683002/ [01:11] StevenK: Comment please. [01:12] wgrant: http://pastebin.ubuntu.com/683003/ [01:12] Better. [01:22] hey btw, the ec2 test results e-mails that get sent, appear to be dateless [01:23] (i.e. no Date: header) [01:23] No, it's just ... timeless [01:24] ewwww very punny :) [01:26] wgrant: Tossing destroy-openidrp back at ec2 [01:27] StevenK: Great. [01:30] ec2test@i-dee51dbe$ sudo shutdown -P +480 & [01:30] That makes me happy [01:33] Applying postgresql configuration changes... [01:33] patching file /etc/postgresql/8.4/main/pg_hba.conf [01:33] patch: **** malformed patch at line 14: [01:33] wgrant: ^^ [01:35] Bah. [01:35] How did that work before :( [01:43] StevenK: 13877 [01:45] does python-coverage work with lp? [01:46] one way to find out [01:48] That sounds fatal. [01:48] oh, it's unlikely to work? [01:50] zope.testrunner is somewhat special. And LP takes 10s or so of CPU time to start even without instrumentation, so it's probably going to be sloooow. [02:00] oh but there is a --coverage [02:25] Project devel build #1,038: FAILURE in 1 hr 21 min: https://lpci.wedontsleep.org/job/devel/1038/ [02:27] :( [02:28] Ah. My fault. [02:43] wallyworld, StevenK: https://code.launchpad.net/~wgrant/launchpad/fix-dbuser-override is ugly, but needs to land within an hour. Could one of you please give it a review? [02:44] wgrant: Did you fix the patch issue? [02:44] Since my ec2 run just utterly broke with [02:44] StevenK: Yes, 13877 [02:44] OperationalError: FATAL: Ident authentication failed for user "launchpad" [02:44] It's what broke jenkins too. [02:45] Let me delete that slave, since it's probably infected [02:45] Heh. It should be OK, but maybe. [02:45] Project devel build #1,039: ABORTED in 19 min: https://lpci.wedontsleep.org/job/devel/1039/ [02:47] wgrant: r=me [03:15] StevenK: Thanks. [04:00] wgrant: my connection's insane again but hope I can get a review for https://code.launchpad.net/~jtv/launchpad/pre-832647/+merge/74087 [04:00] jtv: Sure. [04:01] thanks [04:03] wgrant: you'll be happy to note that I made the unification of [SB]PPH a bit more sustainable. [04:03] I am glad. [04:05] jtv: The name "GeneralizedPublication" made me think it was a wrapper for ?PPH. [04:06] Yes, better suggestions would be most welcome. [04:06] Well, couldn't it be a wrapper? [04:08] Ah, that would make the sort() call awkward. [04:10] Exactly, [04:10] but I did consider it. [04:20] jtv: Approved with comments. [04:21] Thanks. [04:55] Morning. [04:56] O hai [04:56] <-- sleep deprived :( [04:58] nigelb: So situation normal, then? [05:09] haha, sounds familar :) [05:09] btw, not going to bug you folks much today, working on my own project today :) [05:09] G: That's a bug! [05:10] StevenK: "Bug: G is not fully devoted to Launchpad development" ? ;) [05:11] Haha [05:11] Priority: Critical [05:12] to tell the truth, I'm not really that much of a developer, but I do like to dive deep into code, which is kinda funny :) [05:12] StevenK: Ha [05:13] Stayed up for App Developer Week and ended up not being able to sleep. [05:15] wgrant: Your ISP gives you IPv6? [05:16] No, both wgrant and I have a tunnel [05:16] I believe there's roughly one residential ISP in Australia that provides native IPv6. [05:17] Internode only so far [05:17] Telstra will be turning on it "soon" [05:17] StevenK: wow seriously, nice [05:17] Exetel have performed trials, but no news on when the unwashed get it. [05:18] one retail ISP in NZ just went live w/ non Beta native IPv6 [05:18] No idea when Telecom will [05:18] Tunnel to HE.net for me, but it works well [05:19] Both wgrant and I are using AARNet's [05:20] ahhh via the Hexago setup [05:20] I have no complaints [05:20] Most of Linode's location's have native IPv6, and my v6 tunnel has better US routing than native v4, so it's handy. [05:21] There is one crowd that has a tunnel server setup via Sixxs or whatever they are, [05:21] wgrant: I dumped Linode ~6 months ago [05:21] :( [05:21] wgrant: Both Atlanta and London are in internal testing for v6 [05:21] moved my VPS to an LA provider that runs KVM + Native IPv6 etc [05:22] it was back before Linode decided IPv6 was a good thing [05:22] So all 5 should be v6 in a month or so [05:22] well that is something I guess, they dropped the silly policy of charging for anything more than a /128 right? [05:22] G: HE.net's broker is in the same Fremont DC as Linode, so tunnels worked pretty excellently even before it was native. [05:22] I believe so, yes. [05:23] G: Yes [05:23] G: http://www.linode.com/IPv6/ [05:23] wgrant: yeah, I used to use Linode + HE.net Fremont tunnel, but went to ARPnetworks w/ Native IPv6 [05:23] my home IPv6 tunnel terminates in LA, so it's not much of a hop in that direction either [05:24] plus, as the Southern Cross Cable terminates at LA.... well you get the picture :) [05:25] StevenK: wgrant: ahh yep, iirc from the original announcement, they were only offering a /128 and more was $$$ [05:26] I guess enough people told them that was completely stupid. [05:26] G: I waited for the backlash to die down, and then a little while for the kinks and reverse v6 [05:26] yeah, I just laughed [05:27] IPv6 is definately the way to go [05:27] (oh, the other reason why I ditched Linode, was the instability after those crazy outages) [05:27] Which isn't Linode's fault at all [05:28] HE couldn't design a stable DC with help [05:28] StevenK: yeah, but the communication afterwards, wasn't that great either [05:28] (imo anyway) [05:32] and yeah, you are right, HE can't really design datacentres, so it was another good excuse :) [05:33] Personally, I didn't mind either way [05:34] I'm not about to jump up and down and demand Linode fix something that is HE's fault. === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [06:02] stub: Evening. [06:02] hi [06:03] stub: Your --port changes broke staging updates; I removed an assertion and things seem to work again, but I thought you should probably check it. [06:03] ta [06:03] r13878 [06:03] Bug #842284 [06:03] <_mup_> Bug #842284: connect_string can't override the username if already specified < https://launchpad.net/bugs/842284 > [06:04] Also got a couple of other DB-related archaelogy questions when you have some time. === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wgrant | Critical bugs: 254 - 0:[#######=]:256 [06:06] How did that happen? Thought that that assert was already in there. [06:06] It was. [06:06] wgrant: shoot [06:06] But db_options() didn't originally put dbuser in the connection string. [06:07] It just put it in options.dbuser, which pretty much everything that connected to the DB respected. [06:07] oic [06:07] It makes sense, in a not at all and how could somebody do that kind of way. [06:07] its retrofit on retrofit [06:07] yeah. [06:08] I'm ripping out lots of it now. [06:08] All the non-DB scripts just call connect() without a custom username, and canonical.lp is almost dead. [06:08] Kill it! [06:08] Which was one of the other questions: the checks in canonical.lp.sql look reasonably pointless now, and aren't running any more. [06:09] I presume the ZCML inclusion was accidentally dropped somewhere along the line. [06:09] The automatic FROM thing has been off by default since postgres 8.1, so probably hardly worth checking for. [06:10] Those checks used to be useful. Probably not so much now, yeah. [06:11] Maybe the encoding one, but that would be more useful as locale one in any case to confirm the expected collation order. I think we have duplicated these checks elsewhere? [06:11] But yeah, kill 'em. [06:12] Good, I already killed them early in this branch :) [06:12] Thanks. [06:12] wgrant: Does it mean that c.l.sql dies completly? [06:12] No, it will still have initZopeless and isZopeless. [06:12] They need a new home until they die. [06:13] But all the other crap is no longer used except by canonical.launchpad.scripts.db_options, and I hope to eliminate that in a sec by removing the LP_DB* envvars. [06:17] stub: Those envvars are pretty dead, right? :) [06:17] Since we have universal script args now. [06:18] wgrant: Yes. They sometimes get used, but we should be able to use the PG* env vars or the db_options helper for those rare cases. [06:18] Yup. [06:18] db_options is pretty handy. [06:19] All the times they were used recently I think were for work arounds, stuff like accessing a DB on a non-standard port. [06:19] Which is now fixed. [06:19] And PGPORT worked for anyway, IIRC. [06:19] twice :-) [06:19] There's also lots of cruft in database/schema/pending. [06:20] And what is lib/canonical/database/ftests/portforward-to-postgres.tac? :/ [06:20] yer, its pretty much a garbage can for people to stick templates, works in progress etc. [06:20] Hahaha [06:20] Ah. [06:20] That is the old disconnection test harness IIRC, before it moved to Storm. [06:20] It's used by an unused TacTestSetup. [06:20] * wgrant schedules that for deletion. [06:23] database/schema/restoredump.sh looks to be 6.5 years out of date. [07:07] Aha. [07:07] The config is now the sole repository of the DB config. [07:09] \o/ [07:10] Although there is still the extra dbuser in each DBConfig section. [07:11] That is more forgivable, but still needs refactoring. [07:11] Yup. And I suspect we could drop them if we just use the script name as the dbuser [07:11] Overriding the database username was a big WHUI [07:12] Yep. [07:14] Thanks for that. Point me at a MP if you want. [07:15] Still need to work out how the dbconfig.dbuser stuff is tied in. I think I may have missed a spot. [07:16] Looks like it's mostly respected in LaunchpadDatabase.raw_connect, which will probably blow up if a script using it is run with -U... [07:17] But that's not restricted to this branch, and hopefully doesn't affect production. [07:17] We run the database update scripts with -U sometimes [07:17] Yeah, but they don't use the CA, do they? [07:18] They'll use sqlbase.connect, which does a direct psycopg2 connection. [07:19] Not sure - security.py would be the main offender, as we do -U slony to run it directly on the slaves since that is a superuser and has auth all setup. [07:20] security.py is fixed by the assertion removal I pointed you at earlier. [07:20] It uses connect(). [07:20] But the Storm backend has pretty much the same bug, as it turns out. [07:21] But I don't believe we run any normal scripts with -U... only DB maintenance ones. [07:21] Like full-update on staging. [07:21] And no DB maintenance script uses Storm. [07:21] So we are safe for now. [07:23] Hrm, need to do QA. [07:31] wgrant: lagmon might be a problem [07:31] oh no.... connect too [07:33] Yup. [07:35] Argh, ZTM keeps its own copy of connstring components. /me destroys. [07:38] Hi! [07:39] Hello mrevell :) [07:40] I still don't understand why bzr doesn't automatically break insane locks. Or to people really hold their transactions open for a week? [07:42] stub: Have we ever needed storm_cache to be configurable? [07:43] It seems to be the same across the board, except for the dev config's launchpad section, where it's 100 instead of 500. [07:43] Yes. Helped migration when we were switching cache implementations, and currently our scripts run with a smaller cache than the appservers [07:43] Ah, missed that 10000 in there. [07:43] Fair point. [07:51] grar [07:52] jelmer: Oh? [07:52] I was going to ask if we'd broken the importds. [07:52] But we didn't deploy to the importds. [07:52] So that's unlikely. [07:53] good morning [07:54] wgrant: Wrong channel, I was just going to express my annoyance with mumble :) [07:54] g'morning :) [07:54] Ah, heh. [07:54] Morning. [07:54] jelmer: buildbot has succeeded once since you disappeared, and looks like it may again. [07:54] So it may just have been those WorkerMonitorIntegrationScript tests. [07:55] ah, cool [07:55] I also see I wasn't the only one with that password error, thanks for mailing the list about that. [07:56] Yeah, StevenK ran into it. IPv6 as you suspected, so was easily fixed. [08:08] Yippie, build fixed! [08:08] Project devel build #1,040: FIXED in 4 hr 36 min: https://lpci.wedontsleep.org/job/devel/1040/ === almaisan-away is now known as al-maisan [08:17] stub: Any news WRT live patch to migrate away from StaticDiff? [08:18] StevenK: First thing after this coffee :-) [08:19] Landed the patch to drop the dud index [08:40] stub: So the patch to drop the bad index is already in db-devel? [08:46] StevenK: https://pastebin.canonical.com/52285/ [08:46] StevenK: Yes, it has landed already [08:47] StevenK: Can you check those statements over? [08:51] stub: Looks good to me === jelmer is now known as Guest28051 [08:58] StevenK: Done === gmb changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: gmb | Critical bugs: 254 - 0:[#######=]:256 [09:03] stub: As you have a patch hitting db-devel or the migration is done? [09:03] StevenK: Its done [09:04] stub: Excellent, thanks. [09:07] stub: Would you mind commenting on bug 834384 that you've done the migration live on prod? [09:07] <_mup_> Bug #834384: StaticDiff is unused and needs to be shot < https://launchpad.net/bugs/834384 > [09:16] wgrant: no-more-staticdiff tossed at ec2 -- +53 / -615 [09:36] bigjools, wgrant, Laney is asking questions about (I think) distros, blacklisting and suchlike over in #launchpad... Can either of you answer them? [09:42] bigjools: Thanks for - once again - being the Tree of Knowledge-I-haven't-acquired-yet. [09:43] gmb: nae prob, it's brand new functionality that we've done so I don't expect it to be that common yet [09:43] Ah, right. That's why I was even more "Eh? Whut?" about it than normal then. [09:43] :) [09:43] it's all part of derived distros [09:44] you were paying attention in my talk at the Thunderdome right? :) [09:46] pop quiz after a few months is unfair :P [09:50] bigjools: Attention and retention are two different things :) [09:51] (Though I'd figured out that it was derived distro speak; just couldn't get the specifics) [09:59] I didn't work on Launchpad today at all :( === Guest28051 is now known as jelmer [10:13] Oh, sinzui will be back today right? \o/ [10:20] nigelb: I believe he's meant to be, yes. [10:20] wgrant: I have a review pending UI review plus a few UI things I wanted to ask him for help :D === matsubara-afk is now known as matsubara [10:35] nigelb: what is your day job, officially? [10:36] (is launchpad a part of it?) [10:36] jelmer: lolno :) [10:36] My official day job is systems engineer [10:36] which is a far cry from launchpad [10:36] My contributions to Launchpad are entirely voluntary and out of my own interest [10:37] ah, cool :) [10:37] :) [10:40] nigelb: IOW you are pimping to be hired? :) [10:41] bigjools: IOW? [10:41] Oh, hahahaha [10:42] bigjools: I'm running a record breaking run to "Number of rejections by Canonical" :) [10:43] :) [10:50] nigelb: they actually write rejections? aiui you simply get no response ;) [10:51] patrickg: Nah, I've gotten actual rejections. I think my current count is 16. [10:56] you're quite persistent [10:57] heh [10:59] Indeed. [11:07] * gmb -> lunch === al-maisan is now known as almaisan-away === henninge is now known as henninge-lunch [11:45] G: your bug-self-assignment-email branch has landed. I'll Q/A it once it hits staging. All it takes is filing a bug and then assigning it to myself? [11:45] I'll also want to test assigning to someone else; the better part of Q/A is seeing that you didn't break anything that always worked before. :) [11:46] jtv: no, because it only sends the e-mail if you are new to the bug (i.e. never been a subscriber to it effectively) [11:46] jtv: I've QA'ed a few bugs, but PM me when it goes on QAStaging and I'll create the bugs if you want :) [11:47] So I'll have to do it somewhere where I can assign bugs, but am not automatically subscribed to them. [11:47] (a few bugs = my other contributions) [11:48] It's tempting to let you do the work, and nice of you to offer, but I'm afraid the responsibility falls on me. :) I have a separate testing account, so I can play two people. No need to coordinate across timezones etc. [11:52] jtv: okay, no problem :) [11:58] jtv: Ping re https://code.launchpad.net/~jtv/launchpad/bug-834388/+merge/73483 and resultset.set() [11:58] stub: pong re etc. [11:59] jtv: In your fix, is there a chance that the list of ids has been sliced? .set() currently fails when used on a resultset that has been sliced (the slice is ignored, and you attempt setting far more than you wanted to set) [12:00] jtv: nm. checked the code and the ids are listified so it is safe [12:00] Thought so. :) [12:02] jtv: Is there a script that we can run to qa-ok it? Its next up on blocking a rollout (followed shortly by nigelb's branch) [12:03] stub: been working on it since morning. [12:04] ok. I think it just landed on qastaging. [12:06] Who has the qastaging mailbox all setup for a trivial check? [12:08] stub: I'll do my QA in ~2 hours, unless someone else gets to it before me. [12:08] nigelb: You have access to do it? [12:09] stub: No, I have to ask someone else to check once I trigger the email in qastaging [12:09] Which is what I would be doing since I haven't got any mail readers setup :) [12:10] heh [12:13] Hrm, what do I ask to check if I want someone to check the mails on qastaging? [12:13] The staging mailbox [12:14] No, but is there an ID/ something of the particular email that I want checked? === almaisan-away is now known as al-maisan [12:15] FU. [12:15] MPs broken? [12:15] OOPS-2075QASTAGING48 [12:16] OOPS on visiting all MP pages. I can't QA. [12:22] nigelb: Lemme sync logs [12:22] Thanks === henninge-lunch is now known as henninge [12:29] nigelb: Merge proposal diffs are stored in the restricted librarian, which isn't accessible to (qa)staging. [12:29] So you have to create a new one. [12:29] Not use one from prod. [12:29] Ah. [12:30] Can I use an existing branch which doesn't have an MP? [12:30] Apparently I can. [12:30] So, erm, could someone check the mailbox on qastaging for me. [12:31] I'm looking for a Disapproved mail for this branch https://code.qastaging.launchpad.net/~summit-hackers/summit/install-docs/+merge/65302 === salgado_ is now known as salgado [13:31] morning everyone [13:32] o/ flacoste [13:32] bigjools: Halp. [13:33] bigjools: Need the mailbox from qastaging for QA-ing my fix. [13:33] nigelb: under normal circumstances I would help immediately. However, due to the fact that the inbox has currently got 31k messages in it from cronspam kio_imap4 is somewhat struggling :/ [13:34] Ah. Heh. [13:35] I will need to bite the bullet and install t'bird at some point, it handles massive inboxes much better [13:35] What are you using Kmail? [13:36] AFAIK it has slightly better support for IMAP. [13:37] * G personally recommends mutt ;) [13:39] mutt works fine with 31k mailboxes, though it's worth having a header_cache set up. [13:40] I just use mutt w/ Maildir & SSH, but yeah, no problems w/ a default-ish configuration and large maildir folders [13:42] nigelb: yeah kmail. kio_imap4 is not very good, which is a shame because kmail itself is fantastic [13:43] All email clients suck in one way or another. Pick your poison. [13:53] I just use gmail web UI. [14:00] bac: How does ForwardedAuthorization compare to AuthorizationBase.forwardCheckAuthenticated? [14:01] wgrant: complementary. the new one does both checkAuthenticated and checkUnauthenticated. [14:01] Aha. [14:01] there were instances were forwardCheckAuthenticated was still needed so it was kept [14:02] Great, just checking you hadn't somehow missed it. [14:02] Thanks for fixing that. [14:02] wgrant: nope but thanks for asking [14:27] Three successful builds in a row. Quite a novelty. [14:27] * wgrant sleeps. [14:35] stub: Thanks, didn't expect that! [14:35] stub: Part 2 coming up... I might shorten the description if you're going to do it :) [14:41] stub: https://code.launchpad.net/~wgrant/launchpad/destroy-lots-of-db-cruft/+merge/74233, if you're still around. [14:41] jelmer: Hm, is bzr 2.4 meant to be much faster at generating MP diffs, or am I just being very lucky tonight? [14:42] Twice I've had LP diffs within 40 seconds. [14:43] wgrant: lots of things are quicker in 2.4, not sure about MP diffs specifically [14:44] wgrant: 40s is really appalling btw. Generating a diff for a lp tree locally (couple years old machine) takes 20s here locally [14:44] buildbot also seems well and truly fixed, so your bzr stuff is all good, and jenkins seems far more stable with 2.4. Thanks. [14:44] jelmer: 40s is actually not bad, considering the cron job only runs every minute. [14:44] sinzui: O hai. Do you have a minute for a quick UI review? [14:44] I'm assuming you're currently swimming in email. [14:45] jelmer: So it was <40s from MP creation to diff being there (that's just when I refreshed), which includes the time to the start of the next minute, startup time, processing anything that's earlier in the queue, then the actual diff. [14:45] nigelb, I can review. I read email while I am away to ensure my inbox is always zero [14:45] sinzui: free to mumble in a bit? [14:46] sinzui: https://code.launchpad.net/~nigelbabu/launchpad/ubuntu-font-787798/+merge/73793 [14:46] sinzui: Smart man :) [14:46] wgrant: Ah, that seem pretty quick in that case. Still, it should really be instantaneous. [14:46] jcsackett, starting mumble [14:46] nigelb, opening page [14:46] jelmer: Oh yes. [14:46] jelmer: And with rabbitmq it can be. [14:46] And may well be within the year. [14:46] wgrant: I thought you went to bed. [14:47] wgrant: actually, that was a diff between my working tree and lp:launchpad. Generating a diff between a *revision* and the submit branch is less than one second on bzr.dev. [14:47] wgrant: Yeah, rabbit should be great. [14:48] nigelb: But then stub sneakily reviewed one of my branches. [14:49] Haha [14:49] Oh, its not yet 1 am local time. [14:49] it's 10 minutes to EOD for me.. [14:49] (if I would work 9 to 5) [14:50] Meh, call is only at 9am, but I will sleep soon :) [14:50] 9 to 5? HAHAHA [14:50] I haven't worked at 9 am in a long while. [14:50] I start late and end late. [14:51] I conveniently did 9-5 BST (with some effort) when I started in Soyuz and have stuck with that ever since. [14:52] You're bzr team or launchpad team? [14:52] I'm always confused. Until ercently I thought poolie was launchpad team :D [14:53] the rest of us do 9-6 ;) [14:53] Well, bzr was technically a subteam of LP until January. [14:53] still here wgrant? [14:53] Silence! [14:53] Just waiting for a couple of ec2 runs to start. [14:54] Then I may disappear. [14:54]