[00:03] <StevenK> wgrant: The librarian GC is hideous
[00:04] <wgrant> Surely not.
[00:04] <wgrant> But WTF are you doing in there?
[00:04] <wgrant> Ripping out staticdiff?
[00:05] <StevenK> No, it errors since it uses introspection and no longer has access to openidrpconfig
[00:05] <wgrant> OpenIDRPConfig has an LFA?
[00:05] <wgrant> Oh, the logo?
[00:06] <wgrant> So, just leave the permission.
[00:06] <StevenK> Yeah, the logo
[00:06] <wgrant> It must hold it until we drop the FK, which I will do with the other 30.
[00:13] <StevenK> wgrant: http://pastebin.ubuntu.com/682968/
[00:15] <wgrant> StevenK: Interesting, jelmer had the same thing, but it works for stub and I.
[00:15] <wgrant> host localhost
[00:17] <StevenK> .1 and ::1
[00:18] <wgrant> Open up pg_hba.conf, duplicate the 127.0.0.1/32 trust line with ::1/128
[00:18] <wgrant> Reload postgres, and see if that fixes it.
[00:20] <StevenK> wgrant: It does, yes.
[00:22]  * wgrant fixes launchpad-database-setup and mails the list.
[00:23] <wgrant> StevenK: +host    all         all         ::1/128      trust
[00:23] <wgrant> ?
[00:24] <StevenK> "host    all         all         ::1/128           trust" is what I added, yes
[00:25] <wgrant> Hmmm.
[00:25] <wgrant> Interesting.
[00:25] <wgrant> My postgres isn't listening on v6.
[00:25] <wgrant> Possibly because the container I was testing in isn't properly bridged, so it only has a link-local address.
[00:26] <wgrant> But detecting using that sounds pretty hideous.
[00:27] <wgrant> I know glibc did that sort of check to prevent DNS hangs... but postgres?
[00:29] <wgrant> StevenK: Is your listen_addresses setting the default? (commented out or 'localhost')
[00:31] <StevenK> wgrant: It's commented out
[00:31] <wgrant> StevenK: Can I have your /etc/hosts? And is this natty?
[00:33] <StevenK> wgrant: Yes, and http://pastebin.ubuntu.com/682984/
[00:33] <wgrant> That looks either upgraded or mangled.
[00:33] <wgrant> Hah, mangled.
[00:34] <wgrant> I suspect line 6 is the difference. localhost isn't there on my machines.
[00:34] <wgrant> Anyway, I will fix launchpad-database-setup.
[00:34] <wgrant> Thanks.
[00:37] <StevenK> Now the last failure is in xx-person-edit
[00:37] <StevenK> Which now fails since it now prints the OpenID warning everytime
[01:02] <wgrant> StevenK: Jenkins is still happy!
[01:06] <StevenK> Gasp!
[01:11] <StevenK> wgrant: http://pastebin.ubuntu.com/683002/
[01:11] <wgrant> StevenK: Comment please.
[01:12] <StevenK> wgrant: http://pastebin.ubuntu.com/683003/
[01:12] <wgrant> Better.
[01:22] <G> hey btw, the ec2 test results e-mails that get sent, appear to be dateless
[01:23] <G> (i.e. no Date: header)
[01:23] <StevenK> No, it's just ... timeless
[01:24] <G> ewwww very punny :)
[01:26] <StevenK> wgrant: Tossing destroy-openidrp back at ec2
[01:27] <wgrant> StevenK: Great.
[01:30] <StevenK> ec2test@i-dee51dbe$ sudo shutdown -P +480 &
[01:30] <StevenK> That makes me happy
[01:33] <StevenK> Applying postgresql configuration changes...
[01:33] <StevenK> patching file /etc/postgresql/8.4/main/pg_hba.conf
[01:33] <StevenK> patch: **** malformed patch at line 14:
[01:33] <StevenK> wgrant: ^^
[01:35] <wgrant> Bah.
[01:35] <wgrant> How did that work before :(
[01:43] <wgrant> StevenK: 13877
[01:45] <poolie> does python-coverage work with lp?
[01:46] <poolie> one way to find out
[01:48] <wgrant> That sounds fatal.
[01:48] <poolie> oh, it's unlikely to work?
[01:50] <wgrant> 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] <poolie> oh but there is a --coverage
[02:25] <LPCIBot> Project devel build #1,038: FAILURE in 1 hr 21 min: https://lpci.wedontsleep.org/job/devel/1038/
[02:27] <wgrant> :(
[02:28] <wgrant> Ah. My fault.
[02:43] <wgrant> 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] <StevenK> wgrant: Did you fix the patch issue?
[02:44] <StevenK> Since my ec2 run just utterly broke with
[02:44] <wgrant> StevenK: Yes, 13877
[02:44] <StevenK> OperationalError: FATAL:  Ident authentication failed for user "launchpad"
[02:44] <wgrant> It's what broke jenkins too.
[02:45] <StevenK> Let me delete that slave, since it's probably infected
[02:45] <wgrant> Heh. It should be OK, but maybe.
[02:45] <LPCIBot> Project devel build #1,039: ABORTED in 19 min: https://lpci.wedontsleep.org/job/devel/1039/
[02:47] <StevenK> wgrant: r=me
[03:15] <wgrant> StevenK: Thanks.
[04:00] <jtv> 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] <wgrant> jtv: Sure.
[04:01] <jtv> thanks
[04:03] <jtv> wgrant: you'll be happy to note that I made the unification of [SB]PPH a bit more sustainable.
[04:03] <wgrant> I am glad.
[04:05] <wgrant> jtv: The name "GeneralizedPublication" made me think it was a wrapper for ?PPH.
[04:06] <jtv> Yes, better suggestions would be most welcome.
[04:06] <wgrant> Well, couldn't it be a wrapper?
[04:08] <wgrant> Ah, that would make the sort() call awkward.
[04:10] <jtv> Exactly,
[04:10] <jtv> but I did consider it.
[04:20] <wgrant> jtv: Approved with comments.
[04:21] <jtv> Thanks.
[04:55] <nigelb> Morning.
[04:56] <StevenK> O hai
[04:56] <nigelb> <-- sleep deprived :(
[04:58] <StevenK> nigelb: So situation normal, then?
[05:09] <G> haha, sounds familar :)
[05:09] <G> btw, not going to bug you folks much today, working on my own project today :)
[05:09] <StevenK> G: That's a bug!
[05:10] <G> StevenK: "Bug: G is not fully devoted to Launchpad development" ? ;)
[05:11] <StevenK> Haha
[05:11] <StevenK> Priority: Critical
[05:12] <G> 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] <nigelb> StevenK: Ha
[05:13] <nigelb> Stayed up for App Developer Week and ended up not being able to sleep.
[05:15] <nigelb> wgrant: Your ISP gives you IPv6?
[05:16] <StevenK> No, both wgrant and I have a tunnel
[05:16] <wgrant> I believe there's roughly one residential ISP in Australia that provides native IPv6.
[05:17] <StevenK> Internode only so far
[05:17] <StevenK> Telstra will be turning on it "soon"
[05:17] <G> StevenK: wow seriously, nice
[05:17] <StevenK> Exetel have performed trials, but no news on when the unwashed get it.
[05:18] <G> one retail ISP in NZ just went live w/ non Beta native IPv6
[05:18] <G> No idea when Telecom will
[05:18] <G> Tunnel to HE.net for me, but it works well
[05:19] <StevenK> Both wgrant and I are using AARNet's
[05:20] <G> ahhh via the Hexago setup
[05:20] <StevenK> I have no complaints
[05:20] <wgrant> 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] <G> There is one crowd that has a tunnel server setup via Sixxs or whatever they are,
[05:21] <G> wgrant: I dumped Linode ~6 months ago
[05:21] <wgrant> :(
[05:21] <StevenK> wgrant: Both Atlanta and London are in internal testing for v6
[05:21] <G> moved my VPS to an LA provider that runs KVM + Native IPv6 etc
[05:22] <G> it was back before Linode decided IPv6 was a good thing
[05:22] <StevenK> So all 5 should be v6 in a month or so
[05:22] <G> well that is something I guess, they dropped the silly policy of charging for anything more than a /128 right?
[05:22] <wgrant> 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] <wgrant> I believe so, yes.
[05:23] <StevenK> G: Yes
[05:23] <StevenK> G: http://www.linode.com/IPv6/
[05:23] <G> wgrant: yeah, I used to use Linode + HE.net Fremont tunnel, but went to ARPnetworks w/ Native IPv6
[05:23] <G> my home IPv6 tunnel terminates in LA, so it's not much of a hop in that direction either
[05:24] <G> plus, as the Southern Cross Cable terminates at LA.... well you get the picture :)
[05:25] <G> StevenK: wgrant: ahh yep, iirc from the original announcement, they were only offering a /128 and more was $$$
[05:26] <wgrant> I guess enough people told them that was completely stupid.
[05:26] <StevenK> G: I waited for the backlash to die down, and then a little while for the kinks and reverse v6
[05:26] <G> yeah, I just laughed
[05:27] <G> IPv6 is definately the way to go
[05:27] <G> (oh, the other reason why I ditched Linode, was the instability after those crazy outages)
[05:27] <StevenK> Which isn't Linode's fault at all
[05:28] <StevenK> HE couldn't design a stable DC with help
[05:28] <G> StevenK: yeah, but the communication afterwards, wasn't that great either
[05:28] <G> (imo anyway)
[05:32] <G> and yeah, you are right, HE can't really design datacentres, so it was another good excuse :)
[05:33] <StevenK> Personally, I didn't mind either way
[05:34] <StevenK> I'm not about to jump up and down and demand Linode fix something that is HE's fault.
[06:02] <wgrant> stub: Evening.
[06:02] <stub> hi
[06:03] <wgrant> 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] <stub> ta
[06:03] <wgrant> r13878
[06:03] <wgrant> Bug #842284
[06:03] <_mup_> Bug #842284: connect_string can't override the username if already specified <regression> <Launchpad itself:In Progress by wgrant> < https://launchpad.net/bugs/842284 >
[06:04] <wgrant> Also got a couple of other DB-related archaelogy questions when you have some time.
[06:06] <stub> How did that happen? Thought that that assert was already in there.
[06:06] <wgrant> It was.
[06:06] <stub> wgrant: shoot
[06:06] <wgrant> But db_options() didn't originally put dbuser in the connection string.
[06:07] <wgrant> It just put it in options.dbuser, which pretty much everything that connected to the DB respected.
[06:07] <stub> oic
[06:07] <wgrant> It makes sense, in a not at all and how could somebody do that kind of way.
[06:07] <stub> its retrofit on retrofit
[06:07] <wgrant> yeah.
[06:08] <wgrant> I'm ripping out lots of it now.
[06:08] <wgrant> All the non-DB scripts just call connect() without a custom username, and canonical.lp is almost dead.
[06:08] <StevenK> Kill it!
[06:08] <wgrant> 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] <wgrant> I presume the ZCML inclusion was accidentally dropped somewhere along the line.
[06:09] <wgrant> The automatic FROM thing has been off by default since postgres 8.1, so probably hardly worth checking for.
[06:10] <stub> Those checks used to be useful. Probably not so much now, yeah.
[06:11] <stub> 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] <stub> But yeah, kill 'em.
[06:12] <wgrant> Good, I already killed them early in this branch :)
[06:12] <wgrant> Thanks.
[06:12] <StevenK> wgrant: Does it mean that c.l.sql dies completly?
[06:12] <wgrant> No, it will still have initZopeless and isZopeless.
[06:12] <wgrant> They need a new home until they die.
[06:13] <wgrant> 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] <wgrant> stub: Those envvars are pretty dead, right? :)
[06:17] <wgrant> Since we have universal script args now.
[06:18] <stub> 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] <wgrant> Yup.
[06:18] <wgrant> db_options is pretty handy.
[06:19] <stub> 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] <wgrant> Which is now fixed.
[06:19] <wgrant> And PGPORT worked for anyway, IIRC.
[06:19] <stub> twice :-)
[06:19] <wgrant> There's also lots of cruft in database/schema/pending.
[06:20] <wgrant> And what is lib/canonical/database/ftests/portforward-to-postgres.tac? :/
[06:20] <stub> yer, its pretty much a garbage can for people to stick templates, works in progress etc.
[06:20] <StevenK> Hahaha
[06:20] <wgrant> Ah.
[06:20] <stub> That is the old disconnection test harness IIRC, before it moved to Storm.
[06:20] <wgrant> It's used by an unused TacTestSetup.
[06:20]  * wgrant schedules that for deletion.
[06:23] <wgrant> database/schema/restoredump.sh looks to be 6.5 years out of date.
[07:07] <wgrant> Aha.
[07:07] <wgrant> The config is now the sole repository of the DB config.
[07:09] <stub> \o/
[07:10] <wgrant> Although there is still the extra dbuser in each DBConfig section.
[07:11] <wgrant> That is more forgivable, but still needs refactoring.
[07:11] <stub> Yup. And I suspect we could drop them if we just use the script name as the dbuser
[07:11] <stub> Overriding the database username was a big WHUI
[07:12] <wgrant> Yep.
[07:14] <stub> Thanks for that. Point me at a MP if you want.
[07:15] <wgrant> Still need to work out how the dbconfig.dbuser stuff is tied in. I think I may have missed a spot.
[07:16] <wgrant> 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] <wgrant> But that's not restricted to this branch, and hopefully doesn't affect production.
[07:17] <stub> We run the database update scripts with -U sometimes
[07:17] <wgrant> Yeah, but they don't use the CA, do they?
[07:18] <wgrant> They'll use sqlbase.connect, which does a direct psycopg2 connection.
[07:19] <stub> 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] <wgrant> security.py is fixed by the assertion removal I pointed you at earlier.
[07:20] <wgrant> It uses connect().
[07:20] <wgrant> But the Storm backend has pretty much the same bug, as it turns out.
[07:21] <wgrant> But I don't believe we run any normal scripts with -U... only DB maintenance ones.
[07:21] <wgrant> Like full-update on staging.
[07:21] <wgrant> And no DB maintenance script uses Storm.
[07:21] <wgrant> So we are safe for now.
[07:23] <nigelb> Hrm, need to do QA.
[07:31] <stub> wgrant: lagmon might be a problem
[07:31] <stub> oh no.... connect too
[07:33] <wgrant> Yup.
[07:35] <wgrant> Argh, ZTM keeps its own copy of connstring components. /me destroys.
[07:38] <mrevell> Hi!
[07:39] <nigelb> Hello mrevell :)
[07:40] <stub> 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] <wgrant> stub: Have we ever needed storm_cache to be configurable?
[07:43] <wgrant> 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] <stub> Yes. Helped migration when we were switching cache implementations, and currently our scripts run with a smaller cache than the appservers
[07:43] <wgrant> Ah, missed that 10000 in there.
[07:43] <wgrant> Fair point.
[07:51] <jelmer> grar
[07:52] <wgrant> jelmer: Oh?
[07:52] <wgrant> I was going to ask if we'd broken the importds.
[07:52] <wgrant> But we didn't deploy to the importds.
[07:52] <wgrant> So that's unlikely.
[07:53] <adeuring> good morning
[07:54] <jelmer> wgrant: Wrong channel, I was just going to express my annoyance with mumble :)
[07:54] <jelmer> g'morning :)
[07:54] <wgrant> Ah, heh.
[07:54] <wgrant> Morning.
[07:54] <wgrant> jelmer: buildbot has succeeded once since you disappeared, and looks like it may again.
[07:54] <wgrant> So it may just have been those WorkerMonitorIntegrationScript tests.
[07:55] <jelmer> ah, cool
[07:55] <jelmer> I also see I wasn't the only one with that password error, thanks for mailing the list about that.
[07:56] <wgrant> Yeah, StevenK ran into it. IPv6 as you suspected, so was easily fixed.
[08:08] <LPCIBot> Yippie, build fixed!
[08:08] <LPCIBot> Project devel build #1,040: FIXED in 4 hr 36 min: https://lpci.wedontsleep.org/job/devel/1040/
[08:17] <StevenK> stub: Any news WRT live patch to migrate away from StaticDiff?
[08:18] <stub> StevenK: First thing after this coffee :-)
[08:19] <stub> Landed the patch to drop the dud index
[08:40] <StevenK> stub: So the patch to drop the bad index is already in db-devel?
[08:46] <stub> StevenK: https://pastebin.canonical.com/52285/
[08:46] <stub> StevenK: Yes, it has landed already
[08:47] <stub> StevenK: Can you check those statements over?
[08:51] <StevenK> stub: Looks good to me
[08:58] <stub> StevenK: Done
[09:03] <StevenK> stub: As you have a patch hitting db-devel or the migration is done?
[09:03] <stub> StevenK: Its done
[09:04] <StevenK> stub: Excellent, thanks.
[09:07] <StevenK> 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 <Launchpad itself:Confirmed> < https://launchpad.net/bugs/834384 >
[09:16] <StevenK> wgrant: no-more-staticdiff tossed at ec2 -- +53 / -615
[09:36] <gmb> bigjools, wgrant, Laney is asking questions about (I think) distros, blacklisting and suchlike over in #launchpad... Can either of you answer them?
[09:42] <gmb> bigjools: Thanks for - once again - being the Tree of Knowledge-I-haven't-acquired-yet.
[09:43] <bigjools> 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] <gmb> Ah, right. That's why I was even more "Eh? Whut?" about it than normal then.
[09:43] <bigjools> :)
[09:43] <bigjools> it's all part of derived distros
[09:44] <bigjools> you were paying attention in my talk at the Thunderdome right? :)
[09:46] <nigelb> pop quiz after a few months is unfair :P
[09:50] <gmb> bigjools: Attention and retention are two different things :)
[09:51] <gmb> (Though I'd figured out that it was derived distro speak; just couldn't get the specifics)
[09:59] <nigelb> I didn't work on Launchpad today at all :(
[10:13] <nigelb> Oh, sinzui will be back today right? \o/
[10:20] <wgrant> nigelb: I believe he's meant to be, yes.
[10:20] <nigelb> wgrant: I have a review pending UI review plus a few UI things I wanted to ask him for help :D
[10:35] <jelmer> nigelb: what is your day job, officially?
[10:36] <jelmer> (is launchpad a part of it?)
[10:36] <nigelb> jelmer: lolno :)
[10:36] <nigelb> My official day job is systems engineer
[10:36] <nigelb> which is a far cry from launchpad
[10:36] <nigelb> My contributions to Launchpad are entirely voluntary and out of my own interest
[10:37] <jelmer> ah, cool :)
[10:37] <nigelb> :)
[10:40] <bigjools> nigelb: IOW you are pimping to be hired? :)
[10:41] <nigelb> bigjools: IOW?
[10:41] <nigelb> Oh, hahahaha
[10:42] <nigelb> bigjools: I'm running a record breaking run to "Number of rejections by Canonical" :)
[10:43] <bigjools> :)
[10:50] <patrickg> nigelb: they actually write rejections? aiui you simply get no response ;)
[10:51] <nigelb> patrickg: Nah, I've gotten actual rejections. I think my current count is 16.
[10:56] <patrickg> you're quite persistent
[10:57] <nigelb> heh
[10:59] <nigelb> Indeed.
[11:07]  * gmb -> lunch
[11:45] <jtv> 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] <jtv> 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] <G> 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] <G> 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] <jtv> So I'll have to do it somewhere where I can assign bugs, but am not automatically subscribed to them.
[11:47] <G> (a few bugs = my other contributions)
[11:48] <jtv> 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] <G> jtv: okay, no problem :)
[11:58] <stub> jtv: Ping re https://code.launchpad.net/~jtv/launchpad/bug-834388/+merge/73483 and resultset.set()
[11:58] <jtv> stub: pong re etc.
[11:59] <stub> 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] <stub> jtv: nm. checked the code and the ids are listified so it is safe
[12:00] <jtv> Thought so.  :)
[12:02] <stub> 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] <jtv> stub: been working on it since morning.
[12:04] <stub> ok. I think it just landed on qastaging.
[12:06] <stub> Who has the qastaging mailbox all setup for a trivial check?
[12:08] <nigelb> stub: I'll do my QA in ~2 hours, unless someone else gets to it before me.
[12:08] <stub> nigelb: You have access to do it?
[12:09] <nigelb> stub: No, I have to ask someone else to check once I trigger the email in qastaging
[12:09] <stub> Which is what I would be doing since I haven't got any mail readers setup :)
[12:10] <nigelb> heh
[12:13] <nigelb> Hrm, what do I ask to check if I want someone to check the mails on qastaging?
[12:13] <StevenK> The staging mailbox
[12:14] <nigelb> No, but is there an ID/ something of the particular email that I want checked?
[12:15] <nigelb> FU.
[12:15] <nigelb> MPs broken?
[12:15] <nigelb> OOPS-2075QASTAGING48
[12:16] <nigelb> OOPS on visiting all MP pages. I can't QA.
[12:22] <StevenK> nigelb: Lemme sync logs
[12:22] <nigelb> Thanks
[12:29] <wgrant> nigelb: Merge proposal diffs are stored in the restricted librarian, which isn't accessible to (qa)staging.
[12:29] <wgrant> So you have to create a new one.
[12:29] <wgrant> Not use one from prod.
[12:29] <nigelb> Ah.
[12:30] <nigelb> Can I use an existing branch which doesn't have an MP?
[12:30] <nigelb> Apparently I can.
[12:30] <nigelb> So, erm, could someone check the mailbox on qastaging for me.
[12:31] <nigelb> I'm looking for a Disapproved mail for this branch https://code.qastaging.launchpad.net/~summit-hackers/summit/install-docs/+merge/65302
[13:31] <flacoste> morning everyone
[13:32] <bigjools> o/ flacoste
[13:32] <nigelb> bigjools: Halp.
[13:33] <nigelb> bigjools: Need the mailbox from qastaging for QA-ing my fix.
[13:33] <bigjools> 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] <nigelb> Ah. Heh.
[13:35] <bigjools> I will need to bite the bullet and install t'bird at some point, it handles massive inboxes much better
[13:35] <nigelb> What are you using Kmail?
[13:36] <nigelb> AFAIK it has slightly better support for IMAP.
[13:37]  * G personally recommends mutt ;)
[13:39] <cjwatson> mutt works fine with 31k mailboxes, though it's worth having a header_cache set up.
[13:40] <G> I just use mutt w/ Maildir & SSH, but yeah, no problems w/ a default-ish configuration and large maildir folders
[13:42] <bigjools> nigelb: yeah kmail.  kio_imap4 is not very good, which is a shame because kmail itself is fantastic
[13:43] <bigjools> All email clients suck in one way or another.  Pick your poison.
[13:53] <nigelb> I just use gmail web UI.
[14:00] <wgrant> bac: How does ForwardedAuthorization compare to AuthorizationBase.forwardCheckAuthenticated?
[14:01] <bac> wgrant: complementary.  the new one does both checkAuthenticated and checkUnauthenticated.
[14:01] <wgrant> Aha.
[14:01] <bac> there were instances were forwardCheckAuthenticated was still needed so it was kept
[14:02] <wgrant> Great, just checking you hadn't somehow missed it.
[14:02] <wgrant> Thanks for fixing that.
[14:02] <bac> wgrant: nope but thanks for asking
[14:27] <wgrant> Three successful builds in a row. Quite a novelty.
[14:27]  * wgrant sleeps.
[14:35] <wgrant> stub: Thanks, didn't expect that!
[14:35] <wgrant> stub: Part 2 coming up... I might shorten the description if you're going to do it :)
[14:41] <wgrant> stub: https://code.launchpad.net/~wgrant/launchpad/destroy-lots-of-db-cruft/+merge/74233, if you're still around.
[14:41] <wgrant> 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] <wgrant> Twice I've had LP diffs within 40 seconds.
[14:43] <jelmer> wgrant: lots of things are quicker in 2.4, not sure about MP diffs specifically
[14:44] <jelmer> wgrant: 40s is really appalling btw. Generating a diff for a lp tree locally (couple years old machine) takes 20s here locally
[14:44] <wgrant> 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] <wgrant> jelmer: 40s is actually not bad, considering the cron job only runs every minute.
[14:44] <nigelb> sinzui: O hai. Do you have a minute for a quick UI review?
[14:44] <nigelb> I'm assuming you're currently swimming in email.
[14:45] <wgrant> 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] <sinzui> nigelb, I can review. I read email while I am away to ensure my inbox is always zero
[14:45] <jcsackett> sinzui: free to mumble in a bit?
[14:46] <nigelb> sinzui: https://code.launchpad.net/~nigelbabu/launchpad/ubuntu-font-787798/+merge/73793
[14:46] <nigelb> sinzui: Smart man :)
[14:46] <jelmer> wgrant: Ah, that seem pretty quick in that case. Still, it should really be instantaneous.
[14:46] <sinzui> jcsackett, starting mumble
[14:46] <sinzui> nigelb, opening page
[14:46] <wgrant> jelmer: Oh yes.
[14:46] <wgrant> jelmer: And with rabbitmq it can be.
[14:46] <wgrant> And may well be within the year.
[14:46] <nigelb> wgrant: I thought you went to bed.
[14:47] <jelmer> 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] <jelmer> wgrant: Yeah, rabbit should be great.
[14:48] <wgrant> nigelb: But then stub sneakily reviewed one of my branches.
[14:49] <nigelb> Haha
[14:49] <nigelb> Oh, its not yet 1 am local time.
[14:49] <jelmer> it's 10 minutes to EOD for me..
[14:49] <jelmer> (if I would work 9 to 5)
[14:50] <wgrant> Meh, call is only at 9am, but I will sleep soon :)
[14:50] <nigelb> 9 to 5? HAHAHA
[14:50] <nigelb> I haven't worked at 9 am in a long while.
[14:50] <nigelb> I start late and end late.
[14:51] <jelmer> I conveniently did 9-5 BST (with some effort) when I started in Soyuz and have stuck with that ever since.
[14:52] <nigelb> You're bzr team or launchpad team?
[14:52] <nigelb> I'm always confused. Until ercently I thought poolie was launchpad team :D
[14:53] <bigjools> the rest of us do 9-6 ;)
[14:53] <wgrant> Well, bzr was technically a subteam of LP until January.
[14:53] <bigjools> still here wgrant?
[14:53] <wgrant> Silence!
[14:53] <wgrant> Just waiting for a couple of ec2 runs to start.
[14:54] <wgrant> Then I may disappear.
[14:54] <bigjools> uh huh :)
[14:54] <wgrant> I don't have to babysit buildbot tomorrow :D
[14:54] <wgrant> It shall be a productive day.
[14:54] <jelmer> nigelb: poolie and I are both bzr team, though working on other projects occasionally is fun too
[14:54] <nigelb> jelmer: :)
[14:55] <jelmer> there have been some contributions to bzr from lp folk too recently
[14:56] <nigelb> Oh, nice
[14:56] <nigelb> I wish I got over my mental block of staying away from things that are not web apps
[15:11] <jml> nigelb: bzr is *way* easier than LP to contribute to
[15:12] <nigelb> jml: You rickrolled me into contributing for launchpad. Not falling for that again :P
[15:12] <nigelb> (j/k)
[15:12] <nigelb> I like web applications a lot better :)
[15:12] <jml> :)
[15:13] <nigelb> The other thing is, bzr doesn't irritate me. Launchpad does. I'm fixing as much of those bits as I can.
[15:16] <jml> heh heh
[15:19] <stub> bigjools: Did that mbox load?
[15:19] <bigjools> stub: hahaha
[15:19] <nigelb> I can totally picture the evil laugh there
[15:19] <bigjools> muuuuahahahahaaaaaa
[15:19] <stub> I'm thinking of just flagging the bug qa-ok as the actual patch is simple enough that it couldn't possibly go wrong...
[15:19] <nigelb> stub: You're waiting for an inbox fix as well?
[15:20] <nigelb> Or waiting for my QA to deploy.
[15:20] <stub> Or qa-untestable might be better as it technically is untestable :-)
[15:20] <stub> I'd like it qa'd tonight as there should be deployments tomorrow.
[15:20] <nigelb> TEST IN PRODUCTION
[15:20] <nigelb> :)
[15:21] <nigelb> Is there a qa-test-in-production? ;)
[15:21] <stub> qa-untestable :-)
[15:22] <nigelb> Oh, its secret-coded :P
[15:24] <adeuring> gmb: could you please review this MP: https://code.launchpad.net/~adeuring/lazr.batchnavigator/lazr.batchnavigator-no-start-param-for-first-last-url/+merge/74249 ?
[15:24] <gmb> adeuring: Sure
[15:24] <adeuring> thanks!
[15:24] <rvba> gmb: Thanks for your review!
[15:24] <gmb> rvba: No problem.
[15:24] <nigelb> Ha, mrevell replacing himself.
[15:25]  * nigelb just saw it pop up in rss feeds
[15:30] <stub> nigelb, bigjools: I flagged it untestable. It is too simple a patch to let it bureaucratically block stuff.
[15:31] <nigelb> stub: okay :)
[15:43] <gmb> adeuring: r=me with comments
[15:43] <adeuring> gmb: great, thanks!
[15:44] <bigjools> nigelb: mrevell is irreplaceable
[15:45] <nigelb> bigjools: Ha, I tend to agree ;)
[15:45] <adeuring> gmb: good points!
[15:45] <bigjools> nigelb: I vote he clones himselfe
[15:45] <bigjools> himself, even
[15:45] <nigelb> haha
[15:45] <gmb> adeuring: Well, I took jtv's comments about not doing rubber stamp reviews any more to heart :)
[15:46] <benji___> gmb: have a minute for a medium sized review?: https://code.launchpad.net/~benji/launchpad/bug-742662/+merge/74254
[15:46] <gmb> benji: Sure.
[15:47] <nigelb> sinzui: I moved that line into the macro, could you check if its done right?
[15:47] <sinzui> okay
[15:47] <sinzui> nigelb, +1
[15:48] <sinzui> nigelb, I approved the whole review since you addressed bac's concerns
[15:48] <nigelb> sinzui: thanks :)
[15:48] <sinzui> nigelb, I will merge this for you
[15:48] <nigelb> sinzui: Oh, could you land it as well?
[15:48] <nigelb> \o/
[15:48] <nigelb> Thanks
[15:49] <bac> thanks sinzui
[16:37] <jtv> gmb: hah!  you actually read that stuff?  I never thought anyone would.
[16:37] <gmb> benji: Approved. I don't actually have any comments... were there any questions you expected?
[16:37] <gmb> jtv: I generally pay attention to your emails on the flip of a coin, truth be told...
[16:38] <benji> gmb: if you have no questions then I did my job
[16:38] <jtv> gmb: you're being more interesting than usual yourself because this time money seems to be involved.
[16:38] <gmb> :)
[16:38] <jtv> :-P
[16:40] <nigelb> jtv: That was good stuff :)
[16:41] <jtv> nigelb: thanks, I tried English-tradition cocoa instead of Dutch this time.  It's easier to mix.
[16:41]  * nigelb blinks
[18:32] <mtaylor> sinzui: hey! is there a way to bump a bug import request? it's been a few weeks now...
[18:32] <nigelb> mtaylor: He's taking an IRC classroom session atm
[18:33] <mtaylor> nigelb: ah. cool
[18:33] <mtaylor> well - if any losas are around, this: https://answers.launchpad.net/launchpad/+question/168463 as been open since 18 August
[18:34] <thedac> mtaylor: I will take a look
[18:34] <mtaylor> thedac: thanks!
[18:40] <sinzui> mtaylor, I think we need to shout for a LOSA's attention. I expected it to be done with a day of when I set the question back to open
[19:44] <benji> sinzui: is there anything left to do on https://answers.launchpad.net/launchpad/+question/168463 ?
[19:50] <thedac> mtaylor: bug-import has been run on production
[19:51] <mtaylor> thekorn: thank you!
[19:51] <mtaylor> gah
[19:51] <mtaylor> thedac: thank you!
[19:51] <mtaylor> thekorn: (sorry, bad nick completion)
[19:51] <thedac> np
[19:56] <sinzui> benji, based on thedac and mtaylor's remark just after yours, I think the question is really answers and can be marked solved by mtaylor
[19:58] <benji> sinzui: which remark... oh after refreshing the page I see "David Ames (thedac) said 6 minutes ago..."; thanks
[19:59] <sinzui> benji, in irc. between your last two comments
[21:41] <lifeless> abentley: still around ?
[21:41] <abentley> lifeless: yes.
[21:41] <lifeless> I've replied to your mail; if you want a voice chat about it, I could do that too.
[22:35] <abentley> lifeless: I've replied to your reply, but I have one question: is the output of bin/test --list-tests a list of test-ids?
[22:35] <lifeless> bin/test --subunit --list-tests
[22:35] <lifeless> otherwise the zope test machinery inserts gunk in there.
[22:35] <abentley> lifeless: AHHH!
[22:36] <lifeless> indeed
[22:36] <lifeless> thats what I said.
[22:41] <lifeless> abentley: I think we're imagining basically the same thing
[22:41] <lifeless> abentley: I hope I've added clarity, not confusion :)
[22:49] <abentley> lifeless: So is the partitioning happening at a per-test level?  Or are you using information on past runs to estimate how long each test takes?
[22:49] <lifeless> the latter
[22:49] <lifeless> subunit streams are datestamped
[22:50] <abentley> lifeless: makes sense.
[22:50] <lifeless> we get per-test durations from this, and there is a small db in the .testrespository directory that holds all the seen test ids -> duration
[22:51] <lifeless> so partitioning is make N buckets, allocate to the lowest accumulated time bucket the next largest test for all known test durations, then round robin for all unknown test durations.
[23:02] <wallyworld_> sinzui: can you hear me?
[23:02] <sinzui> no, but I am killing thunderbirf
[23:02] <sinzui> I will restart mumble after the murder is complete
[23:53] <sinzui> wgrant, lp:~sinzui/bzr-gtk/gtk3 works, though I am seeing gtk3 warnings that is why I delayed proposing it
[23:59] <sinzui> StevenK, https://bugs.launchpad.net/launchpad/+bug/485126
[23:59] <_mup_> Bug #485126: Accidentally unsubscribing myself from a private bug makes the bug inaccessible <disclosure> <lp-bugs> <privacy> <Launchpad itself:Triaged> < https://launchpad.net/bugs/485126 >