[00:34] <wgrant> wallyworld_, StevenK: Please don't force buildbot yet.
[00:35] <wallyworld_> ok
[00:35] <wgrant> wallyworld_: However, I do need an urgent review for https://code.launchpad.net/~wgrant/launchpad/connectionstring-hates-production/+merge/74321
[00:35] <wgrant> If you have a sec.
[00:35] <wallyworld_> sure
[00:36] <wgrant> Copyright year fail.
[00:36] <wgrant> Fixing.
[00:40] <wallyworld_> wgrant: shoud the test for changes include the case where the key being changed is in the original connection string, as well as just adding a new key value?
[00:41] <wgrant> wallyworld_: Probably, yes.
[00:41]  * wgrant fixes.
[00:41] <wallyworld_> thanks
[00:46]  * wallyworld_ wants longpoll NOW. hitting refresh on a mp is a pita
[00:48] <wgrant> Diff has updated.
[00:48] <wallyworld_> wgrant: r-me. thanks
[00:48] <wgrant> Thanks.
[01:00] <StevenK> wgrant: r13862 is marked as bad, what rev is the relevant fix/rollback?
[01:01] <StevenK> [r=henninge][no-qa] Sort utilities/sourcedeps.cache. Finally.
[01:01] <StevenK> Oh, Henning!
[01:02] <StevenK> G: You have two revs to QA -- bug 697157 and bug 841658
[01:02] <_mup_> Bug #697157: Streamline "You have assigned this bug to yourself" message  <bugs> <qa-needstesting> <trivial> <ui> <Launchpad itself:Fix Committed by dev-nigelj> < https://launchpad.net/bugs/697157 >
[01:02] <_mup_> Bug #841658: DistroSeries/DistroArchSeries API link does not return any entries <api> <qa-needstesting> <trivial> <Launchpad itself:Fix Committed by dev-nigelj> < https://launchpad.net/bugs/841658 >
[01:04] <G> StevenK: jtv said he was going to QA 697157 because it's his responsibility ;)
[01:04] <StevenK> wgrant: Any idea how to QA bug 841850?
[01:04] <_mup_> Bug #841850: OpenIDRPSummary continues to exist <qa-needstesting> <Launchpad itself:Fix Committed by stevenk> < https://launchpad.net/bugs/841850 >
[01:04] <G> but I'll test 841658 now :)
[01:04] <G> StevenK: it's on qastaging now right?
[01:05] <StevenK> G: Aye
[01:06] <wgrant> StevenK: Acquire a user without PPAs (or ask me to use one of my test accounts), ensure that renaming displays the warning sensibly, and that acknowledging it works.
[01:07] <StevenK> wgrant: I have a PPA, so I think it should be one of your test accounts
[01:07] <StevenK> And I don't really want to launch into the mess of deleting it just to QA something :-/
[01:08] <G> StevenK: yep, 658 looks correct, I'll mark it qa-ok
[01:09] <wgrant> StevenK: You can't delete it, because qastaging doesn't have a publisher.
[01:10] <StevenK> So not signing up for a new account on qas :-)
[01:11]  * wgrant is doing it.
[01:11] <wgrant> qa-ok
[01:12] <StevenK> wgrant: So marked, thanks
[01:16] <StevenK> No staticdiffs against Launchpad. Bah
[01:16] <wgrant> Hm, sure?
[01:16] <StevenK> Perhaps I should get the LOSAs to actually do the migration on qastaging ...
[01:16] <wgrant> You didn't accidentally commit the migration, did you?
[01:17] <StevenK> On DF? I don't think so
[01:17] <wgrant> You can't use the presence of staticdiffs for QA.
[01:17] <wgrant> Because you can't view prod diffs on qastaging.
[01:17] <StevenK> launchpad_dogfood=# SELECT count(*) from branchmergeproposal where review_diff is not null and merge_diff is null; => 5251
[01:17] <wgrant> Just check the a new preview diff works OK.
[01:17] <wgrant> No need to QA the migration you did yesterday.
[01:18] <StevenK> So create a new MP and check the diff gets generated?
[01:19] <wgrant> yes.
[01:19] <wgrant> Ideally check that revision mail still works too.
[01:19] <wgrant> So...
[01:20] <wgrant> Push up a new branch.
[01:20] <wgrant> Subscribe to revision mail.
[01:20] <wgrant> Push up some new revisions.
[01:20] <wgrant> Scan the branch.
[01:20] <wgrant> Push up some more new revisions.
[01:20] <wgrant> Scan the branch again.
[01:20] <wgrant> Uncommit and push.
[01:20] <wgrant> Scan the branch again.
[01:20] <wgrant> Create a merge proposal somewhere (doesn't need to be same branch), and check that the diff is generated.
[01:23]  * StevenK works through that list slowly
[01:24] <StevenK> According to https://code.qastaging.launchpad.net/~stevenk/+junk/foo I'm already subscribed?
[01:24] <wgrant> Not to revision diffs.
[01:24] <wgrant> Probably only to merge proposals.
[01:25]  * StevenK changes his subscription
[01:25] <StevenK> Do I need a LOSA to run the scanner?
[01:25] <wgrant> Yes.
[01:31] <wgrant>  45 files changed, 127 insertions(+), 801 deletions(-)
[01:31] <wgrant> ow
[01:38] <StevenK> wgrant: The scanner has been run, but the branch page still says Updating ...
[04:21] <Lifelrss> Way too much cron spam
[04:23] <wgrant> Yes.
[04:23] <wgrant> It is mildly insane.
[04:24] <wgrant> Just don't look at the staging mailbox.
[04:25] <Lifelrss> It's disturbing cynthia. Can fix ?
[04:25] <wgrant> BHeh
[04:26] <wgrant> Well. Part of it needs an RT that is way down the queue fixed.
[04:26] <wgrant> Other parts need hloeung.
[04:26] <Lifelrss> The apt pyrge thingy?
[04:27] <wgrant> Yes.
[04:28] <Lifelrss> Meep
[04:28] <wgrant> We got to 260 on Monday :)
[04:28] <Lifelrss> Uhm, perhaps that ticket should be higher. It's not in fhe losa queue
[04:28] <Lifelrss> Afaik
[04:29] <wgrant> LOSAs can't do it.
[04:29] <wgrant> So perhaps it shouldn't be in the LOSA queue.
[04:29] <wgrant> But it is in the LOSA queue.
[04:29] <wgrant> #9
[04:29] <Lifelrss> Right :)
[04:29] <wgrant> You have priority powers, feel free to use them :)
[04:30] <Lifelrss> Talking to a gsa will be fadter
[04:30] <wgrant> Nobody else subscribed to the list has powers.
[04:30] <Lifelrss> Sm kn phone
[04:30] <wgrant> Heh.
[04:30] <StevenK> What the heck are you typing on?
[04:30] <StevenK> Or *with*
[04:30] <wgrant> Im on phone
[04:30] <wgrant> I assume.
[04:30] <Lifelrss> Yes
[04:30] <hloeung> lifeless may be teaching cynthia how to type already
[04:30] <wgrant> Or perhaps Cynthia is proxying for him.
[04:30] <wgrant> Heh
[04:31] <StevenK> It could have been a dvorak keyboard via a pencil in the mouth given the typos
[04:31] <Lifelrss> cinerama: ^
[04:33] <Lifelrss> If you could move that ticket around for yts that would be awesome
[04:34] <wgrant> https://rt.admin.canonical.com//Ticket/Display.html?id=47596 is the ticket.
[04:34] <wgrant> But there is no vanguard today.
[04:34] <StevenK> cocoplum has one too
[04:35] <wgrant> Yeah, there are lots.
[04:35] <StevenK> I saw it with the paste from the dapper destruction
[04:36] <wgrant> I really should just have reverted Chameleon while it was easy :/
[04:43] <nigelb> Woah, Cynthia is already on IRC?
[04:43] <StevenK> She should post her first branch in a few days
[04:43] <StevenK> First landing in trunk in what, a week?
[04:44] <nigelb> I guess so
[04:45] <nigelb> buildbot failed again :(
[04:45] <wgrant> Yeah. Something leaked a forkingservice again.
[04:45] <wgrant> 1:20 to go on the next run.
[04:46] <wgrant> Jenkins remains stable.
[04:47] <StevenK> It's hard to leak stuff between runs when the entire instance is shot in the head
[05:31] <jtv> Is it okay for a package publication to be superseded but not have supersededby set?
[05:39] <jtv> StevenK, wgrant: this may happen if we allow multiple versions of a package to survive domination: a publication may become superseded but without a clear dominant.  The schema allows it, but won't it break anything?
[05:40] <wgrant> jtv: No, it's only used by the UI.
[05:40] <jtv> So it's fine to say "superseded, but not by any particular release"?
[05:40] <wgrant> jtv: And deletions from before ArchiveRemovalRedesign are already Superseded without a supersededby
[05:41] <jtv> Very very few.
[05:41] <wgrant> Try to avoid it, but it's legal and acceptable.
[05:41] <wgrant> How is there not a clear dominant, though?
[05:41] <wgrant> Can't you just use the oldest live one after the publication?
[05:41] <jtv> Idiot.
[05:42] <wgrant> Oh?
[05:42] <jtv> Heh.  I'm asking about the case where there isn't one, of course.
[05:43] <wgrant> If there is no newer live publication, isn't it probably Deleted?
[05:44] <jtv> That's the kind of thing I'm asking about.  Think "latest version of a package is removed from Debian Sources list, leaving only the previous version."
[05:45] <cinerama> lifeless, wgrant: ok, i see the RT, i'll just go and see what we are going to do
[05:45] <jtv> I could mark that as superseded (but by which version?) or as deleted.
[05:46] <wgrant> jtv: Seems likely it's Deleted if there's nothing to supersede it.
[05:46] <wgrant> "likely"
[05:46] <jtv> How would we know the difference?
[05:46] <wgrant> cinerama: Thanks. I know the issue fairly well, so can hopefully clarify anything that needs it.
[05:46] <wgrant> What difference?
[05:46] <wgrant> If there something newer alive -> superseded
[05:46] <wgrant> Otherwise -> deleted
[05:46] <jtv> Between a deleted one and a superseded one in this situation?
[05:47] <jtv> So you meant "likely" as in "I'm not sure"?
[05:47] <wgrant> No, I'm sure that it's true in most cases.
[05:47] <jtv> Then how do we tell the difference between cases where it is and cases where it isn't?
[05:48] <wgrant> We probably can't.
[05:48] <wgrant> The status doesn't make a huge difference. I think the method I described will get it right just about all the time.
[05:51] <jtv> OK
[05:56] <wgrant> G: Around?
[05:59] <G> wgrant: yo
[05:59] <wgrant> G: Do you have a moment now to QA bug #697157?
[05:59] <_mup_> Bug #697157: Streamline "You have assigned this bug to yourself" message  <bugs> <qa-needstesting> <trivial> <ui> <Launchpad itself:Fix Committed by dev-nigelj> < https://launchpad.net/bugs/697157 >
[06:00] <wgrant> G: I can grab the mail from qastaging's mailbox.
[06:00] <wgrant> Or I can do the whole thing.
[06:00] <G> wgrant: jtv, said he was going to QA it but if you want to
[06:00] <G> wgrant: I'll create two bugs and you can do the rest if you want
[06:03] <G> wgrant: your LP login is wgrant I take it?
[06:03] <wgrant> G: Indeed it is.
[06:03] <wgrant> Note that it can't be a bug on any of the Launchpad projects, because I'm already subscribed to all of them.
[06:04] <G> wgrant: you should have got a correct message about me assigning you https://bugs.qastaging.launchpad.net/pymheg2xmltv/+bug/800256
[06:04] <_mup_> Bug #800256: Blue Triangle, top left, next to BFB. <Ayatana Design:New> <unity:Invalid> <unity (Ubuntu):Invalid> < https://launchpad.net/bugs/800256 >
[06:04] <wgrant> Nigel Jones (dev-nigelj) has assigned this bug to you for MHEG5 to XMLTV Converter:
[06:04] <G> wgrant: and if you assign https://bugs.qastaging.launchpad.net/pymheg2xmltv/+bug/800257 to yourself...
[06:05] <wgrant> You have assigned this bug to yourself for MHEG5 to XMLTV Converter:
[06:05] <wgrant> Looks good. Thanks.
[06:06] <cinerama> wgrant: ok, so i've removed the egg info and reinstalled where i found python-tz, didn't see python-setuptools as i was expecting
[06:06] <wgrant> cinerama: The package often isn't installed any more.
[06:06] <wgrant> In that cause just remove the directory.
[06:06] <wgrant> s/cause/case/
[06:06] <G> wgrant: np, happy to help
[06:06] <G> is there another downtime-less update happening overnight or something?
[06:07] <wgrant> With a bit of luck we'll do one in about an hour.
[06:07] <wgrant> Need to QA incoming bugmail now, though :(
[06:08] <G> back to getting a sane xmltv file for my mythtv setup :)
[06:08] <wgrant> Good luck with that.
[06:09] <wgrant> I never had much luck.
[06:09] <G> wgrant: I'm processing the MHEG data directly :)
[06:09] <wgrant> G: Doesn't MythTV normally do that itself?
[06:10] <wgrant> Ah, no, that's not MHEG.
[06:10] <G> I've been using an xmltv file that someone creates using the Satellite EIT data, but the DVB-T (OTA) service doesn't really have much EIT data
[06:11] <cinerama> wgrant, lifeless: ok, looks like we should be rid of those bad eggs
[06:11] <wgrant> cinerama: Thanks. Which hosts did you clean?
[06:11] <G> problem is, the Satellite data doesn't always match the DVB-T data :)
[06:11] <cinerama> wgrant: the ones mentioned in your ticket for hloeung
[06:16] <wgrant> cinerama: Thanks. Logging changes over the last couple of days have revealed four more that need fixing :( I've just updated the ticket.
[06:16] <wgrant> hloeung: ^^
[06:26] <cinerama> wgrant: ok, i think we've tidied up the others now
[06:27] <wgrant> cinerama: Great. There's probably another host or two that isn't spamming dozens of times an hour and has been drowned out until now, but I'll update the ticket later if so.
[06:27] <wgrant> Thanks!
[06:28] <cinerama> wgrant: sounds good.  i am going to leave the ticket with the losas since they can do most of it and can just poke a gsa for help
[06:28] <wgrant> Oh, can they?
[06:28] <wgrant> Didn't know that :(
[06:29] <wgrant> The staging mailbox has gone three minutes without a dozen messages a minute. This is good progress!
[06:29] <hloeung> we can poke GSAs for help - that's "most of it"
[06:32] <wgrant> Heh
[06:37] <cinerama> yay, let's open some champagne to celebrate
[06:45] <wgrant> cinerama: Hm, tellurium seems to still have pytz.
[06:47] <wgrant> ... and asuka just showed up with 11 pytz-whining emails too :(
[06:50] <cinerama> ugh, need to clean up /usr/lib/python2.6 stuff as well as /usr/share/pyshared stuff
[06:50] <cinerama> brb
[07:01] <wgrant> germanium too.
[07:02] <wgrant> nigelb: Your webfonts stuff looks good.
[07:05] <wgrant> Hm, actually.
[07:07] <wgrant> It's fine in Chromium, but Firefox 7 doesn't display the bold fonts properly.
[07:08] <wgrant> It seems to scale up the normal weight.
[07:08] <lifeless> cinerama: wgrant: thank you both very much
[07:09] <cinerama> there still appear to be some broken links for eggs in that area for packages you haven't mentioned -- do i need to fix those up as well?
[07:13] <wgrant> cinerama: They're not being noisy, but if you want to...
[07:28] <cinerama> ok, i think i've properly dealt with pytz
[07:42] <adeuring> good morning
[07:44] <wgrant> cinerama: Thanks.
[07:45] <nigelb> wgrant: Oh. Its in production? \o/
[07:46] <StevenK> It is not
[07:46] <nigelb> ah, qastaging.
[07:47]  * StevenK digs for canonical_url
[07:47] <StevenK> So tempted to move it to lp.app
[07:48] <StevenK> But the diff would be LARGE
[07:50] <wgrant> nigelb: I think it may need further work; see the bug for details.
[07:50] <nigelb> wgrant: I saw. Need to get back home to test on my machine.
[07:50]  * nigelb just got to work
[07:51] <nigelb> I'm using Firefox 8 though.
[07:52] <nigelb> wgrant: Do you want to qa-bad that or just want me land a better fix later today?
[07:53] <wgrant> nigelb: I don't think it's worth marking it bad.
[07:53] <wgrant> Particularly given we're already fairly blocked.
[07:53] <nigelb> heh, ok :)
[07:53] <wgrant> Some bold fonts will look bad on some browsers for a day. Meh.
[07:54] <nigelb> Yeah, stub marked my email fix as qa-untestable for faster deployment :)
[07:54] <wgrant> That deployment sadly failed.
[07:54] <nigelb> Oh. Why?
[07:54] <nigelb> :(
[07:55] <wgrant> Changes to DB connection string handling meant that hostnames with hyphens didn't work. Staging and dev use underscores, production uses hyphens, boom.
[07:56] <StevenK> Do we have a ... um, something for a "Are you sure?" action?
[07:56] <wgrant> There is a new confirmation overlay that rvba or allenap has been working on.
[07:57] <wgrant> And the bug assignee picker already has a confirmation page at the end.
[07:57] <allenap> wgrant: rvba I think.
[08:09] <rvba> StevenK: ConfirmationOverlay
[08:10] <rvba> StevenK: It's meant to be used to 'protect' an existing submit button. Very much like the js 'confirm' method.
[08:10] <mrevell> Howdy
[08:22] <allenap> Morning mrevell :)
[08:22] <allenap> Who wants to do a review?
[08:23] <allenap> https://code.launchpad.net/~allenap/launchpad/pcj-more-often-bug-770721-pre/+merge/74293
[08:23] <allenap> Please :)
[08:28] <StevenK> allenap: r=me
[08:28] <allenap> StevenK: Thanks :)
[08:34] <lifeless> jamesh: am I right that the only missing thing to migrate to oops-wsgi is an answer for storm query capturing ?
[08:36] <jamesh> lifeless: that's the main one I've identified.  That said, we've got code to handle this, so I could wire it up with python-oops
[08:37] <jamesh> lifeless: I need to follow up with a few others on the U1 team though to see if there is anything else.
[08:37] <lifeless> the thing blocking me extracting the tracer we use from LP is identifying 'current request'
[08:38] <lifeless> because 'current transaction' doesn't seem like a good match
[08:38] <jamesh> lifeless: https://wiki.canonical.com/UbuntuOne/Futures/Notes/PythonOops has my in-progress notes for moving over.
[08:38] <lifeless> unless we inject 'this is the oops-in-progress' into the tracer from a wsgi decorator
[08:39] <lifeless> in which case we need a storm-timeline tracer (which could go in storm itself), and a storm-wsgi which would have a thin wsgi app to set and unset the timeline that the tracer should use
[08:39] <lifeless> does this sound sane ?
[08:41] <jamesh> lifeless: one other case I'd like to eventually handle (as in "I don't think we currently do it but it would be nice") would be tracing statements in the API server
[08:41] <lifeless> what sort of statements ?
[08:41] <lifeless> do you mean like a custom debug hook that logs rather than profiling/debugging ?
[08:41] <jamesh> it is a twisted daemon that performs DB transactions via deferToThread()
[08:41] <lifeless> cause that would be the bomb.
[08:42] <jamesh> still storm statement tracing, but not in a "one thread per request" model
[08:42] <lifeless> oh right
[08:42] <jamesh> I guess a "this is the current timeline" API would handle that though.
[08:42] <lifeless> uhm, so that seems straight forward, have a wrapper - deferToThread(setTimeline, timeline, realthingtocall, realparams)
[08:42] <jamesh> right.
[08:43] <StevenK> rvba: Are you off the stand-up?
[08:45] <jamesh> lifeless: I haven't looked the python-timeline package you're using in LP yet.  I guess it would be worth looking at together with the other OOPS stuff though.
[08:45] <lifeless> jamesh: its tiny, but yeah
[08:46] <lifeless> jamesh: we put memcached call-outs, google search API calls, librarian operations, storm queries all into the timeline
[08:46] <lifeless> jamesh: lets us see slow backend API's
[08:46] <wgrant> (and SSO!)
[08:47] <rvba> StevenK: not yet.
[08:47] <jamesh> lifeless: I guess that is a bit more structured than just capturing all logging messages to the oops report ...
[08:47] <jamesh> [that seems to be the equivalent functionality from the wsgi-oops package we're using]
[08:48] <lifeless> yeah
[08:48] <lifeless> log messages are fine
[08:48] <lifeless> but this is introspectable
[08:49] <lifeless> so we can get duration, which log messages don't have
[08:49] <lifeless> and that lets oops-tools tell us that '5400ms were taken up by repeated query Y'
[08:50] <lifeless> and be confident that its that, and not slow python code post-query, for instance.
[08:50] <jamesh> yep.
[08:50] <lifeless> you could do that with log messages with a well-known-form
[08:50] <rvba> StevenK: ?
[08:51] <lifeless> but IMO it gets a bit ugly having a heuristic to ditch ones not matching it
[08:53] <jamesh> I'm not suggesting you switch to the logging module.
[08:53] <lifeless> no :)
[08:53] <lifeless> I was just being verbose
[08:54] <lifeless> jamesh: do you think the tracer belongs in core storm? will add the dependency on the timeline module for testing at least.
[08:55] <StevenK> rvba: You're working on a confirmation overlay?
[08:55] <jamesh> lifeless: we've got a number of optional modules in Storm already: storm.zope (which you're using) and storm.django (which we're using).
[08:56] <jamesh> one more wouldn't be out of place
[08:56] <rvba> StevenK: It's already in the code actually: lib/lp/app/javascript/confirmationoverlay/confirmationoverlay.js
[08:56] <StevenK> rvba: Nice!
[08:57] <rvba> StevenK: It's used on +localpackagediffs to add a confirmation overlay when you're about to sync stuff.
[08:57] <StevenK> rvba: I was about to ask
[08:57] <StevenK> I was going to use it to solve a disclosure bug
[08:57] <rvba> StevenK: See lib/lp/registry/templates/distroseries-localdifferences.pt
[08:58] <rvba> StevenK: I hope it can suit your needs without modification.
[08:58] <StevenK> rvba: That would be nice, I'll dig tomorrow, thanks for the help.
[08:59] <rvba> StevenK: np.
[08:59] <rvba> StevenK: when it's not timing out, you can see it in action and play with it https://dogfood.launchpad.net/ubuntu/oneiric/+localpackagediffs
[09:38] <jtv> Is it just me or are EC2 tests not working?
[10:24] <bigjools> jtv: I dunno, are you not working?
[10:24] <jtv> bigjools: I am, but ec2 isn't.
[10:24] <jtv> I get timeouts and hanging instances.
[10:26] <rvba> jtv: I lannched an instance 1 hour ago without problem.
[10:26] <jtv> Thanks.  Blast.
[10:32] <lifeless> stub: hey there
[10:33] <stub> hiya!
[10:33] <lifeless> stub: python-pgbouncer seems to have some skew in its version numbers - __init__ says 0.0.1, setup.py 0.0.2 and pypi 0.0.3 ;)
[10:33] <lifeless> stub: I'm really glad you updated it :)
[10:33] <lifeless> stub: I was worried I hadn't setup enough permissions
[10:34] <stub> setup.py should have 0.0.3 too since that is what is used to build and upload the package to pypi
[10:34] <stub> Didn't think of a number in __init__, but now I think of it I've had setup.py pull the version number from __init__ before.
[10:35] <lifeless> yeah, me too in other projects
[10:35] <lifeless> need to copy that glue across
[10:35] <lifeless> hey, so fastdowntime seems to be awfully close
[10:35] <lifeless> nice work
[10:36] <stub> Just trying to get the know issues stuff landed.
[10:36] <lifeless> yah
[10:36] <lifeless> we always knew there would be rabbits in holes.
[10:36] <lifeless> its pretty awesome getting it all flushed out
[10:37] <stub> I'll hack around lag mon with PGPORT instead of --port so I don't have to worry about that crud for now. I think the wanted revs are otherwise in place now, which I'll check after I've updated these rollout scripts for ISD.
[10:37] <lifeless> lynne is having some trouble, I -may- not be back next week. I'll let you know when I let francis know (which will be ~ 5 minutes after I know :P)
[10:37] <stub> Yup. No worries. Reviews have been pretty boring.
[10:38] <lifeless> they always are... until you get one that terrifies :)
[10:38] <stub> need to ensure we don't lose google juice with async loading of comments, and privacy is making some of the branch queries go recursive (if your stacked on branch is private, you are private too even if you claim to be public). But the queries I've seen so far are fast.
[10:39] <lifeless> I believe google have js execution in their crawlers now
[10:39] <lifeless> to handle twitter et al
[10:40] <stub> Good luck with Lynne and the spawn too!
[10:40] <lifeless> thanks ;)
[10:41] <lifeless> 'spawn' is smiling and gurgling cutely already.
[10:42] <wgrant> I think we probably want a boring old batched comment listing, as well as the async loading.
[10:42] <lifeless> async should batch as well
[10:42] <stub> yer, thats what I said. I don't think we lose with what is behind the FF at the moment either.
[10:42] <lifeless> faster for the only-reads-a-few case
[10:43] <lifeless> and permits scroll-to-end etc
[10:43] <lifeless> but thats efuture :)
[10:49] <wgrant> stub: We should be OK to deploy the port fix in an hourish.
[10:49] <wgrant> stub: Did you see the fireworks overnight?
[10:50] <stub> Apart from the bug being flagged as rolled back, I don't know what happened.
[10:50] <wgrant> Well, ConnectionString thought that connection string values were in \w+
[10:50] <wgrant> \w is roughly [a-zA-Z0-9_]
[10:50] <wgrant> Production DNS aliases have hyphens...
[10:51] <wgrant> So host=lp, and boom.
[10:51] <stub> blah
[10:51] <wgrant> And because of our marvellously unified database connection mechanisms, appservers were not affected so it wasn't noticed for a while.
[10:52] <wgrant> Still, Zopeless is now very nearly dead.
[10:52] <stub> wgrant: So you have landed the fix and it is with ec2 or buildbot atm?
[10:52] <wgrant> stub: It's been on qastaging for a few hours now.
[10:52] <wgrant> Just waiting on three revs of QA.
[10:52] <wgrant> bigjools, henninge: ^?
[10:52] <stub> Thankyou very much. I should sleep in more often :-)
[10:52] <henninge> wgrant: will be a little longer
[10:53] <wgrant> The connection string syntax supports escaping and quoting, but I decided we needed a quick fix so just added an assertion to prevent unnoticed misparsing of those cases.
[10:53] <wgrant> So it just uses [^ ]+ instead of \w+
[10:53] <bigjools> patience
[10:53] <bigjools> ffs
[10:54] <stub> Yes, I think that is the better approach too
[10:55] <wgrant> stub: If someone tries to use a space in a username, hostname or database name, they probably deserve a crash :)
[10:56] <stub> Yes :-) On my list is to switch all the usernames using hyphen to using underscore too, and block hyphen in security.py. Quoting the names is annoying.
[10:59] <wgrant> Yeah, although that's fairly well encapsulated now.
[10:59] <wgrant> Before I rewrote half of it it was quoting and unquoting everywhere :(
[11:02] <wgrant> stub: https://code.launchpad.net/~wgrant/launchpad/more-zopeless-destruction/+merge/74367 may be of interest
[11:03] <wgrant> Pretty simple continuation of the series.
[11:03] <wgrant> But gets rid of most of the rest of ZTM's non-wrapper bits.
[11:04] <henninge> wgrant: I am having a problem with that revision
[11:04] <wgrant> Uhoh.
[11:05] <henninge> wgrant: It is not fixing the bug, just movingn an exception being raised from the UI to a script run.
[11:05] <wgrant> Heh.
[11:05] <henninge> where it is more likely to cause problems
[11:06] <henninge> or be ignored ...
[11:06] <henninge> wgrant: Unfortunately there does not seem to have been a pre-implementation chat with translations people.
[11:06] <wgrant> bad enough to need a revert?
[11:06] <wgrant> It sounds pretty rare.
[11:07] <henninge> I hope jtv is around for a second opion.
[11:07] <jtv> what now?
[11:07] <henninge> ;-)
[11:07] <henninge> jtv: Hi!
[11:07] <jtv> hi!
[11:07] <henninge> jtv: can you please have a look at https://code.launchpad.net/~benji/launchpad/bug-742662/+merge/74254 ?
[11:07] <jtv> OK
[11:08] <henninge> jtv: I am not sure it is an improvement.
[11:08] <jtv> Wait… we always did report mixed newlines, didn't we?
[11:09] <henninge> jtv: yes, it currently happens when submitting translations.
[11:09] <henninge> (see the OOPSes)
[11:09] <henninge> in the UI.
[11:09] <henninge> This branch moves the check into the importer.
[11:09] <henninge> Which would be fine if the exception was caught and added to "errors".
[11:10] <jelmer_> wgrant: hi
[11:10] <henninge> jtv: I don't like uncaught exceptions in the importer ...
[11:10] <wgrant> jelmer_: Morning.
[11:10] <jelmer_> wgrant: I saw something in the logs about an import test leaving processes around?
[11:10] <wgrant> jelmer_: Something is occasionally leaving a forking service around.
[11:11] <wgrant> The buildbot logs aren't a timestamped subunit stream, so I can't tell what.
[11:11] <wgrant> But you can see the sort of failure it happens around at https://lpbuildbot.canonical.com/builders/lucid_lp/builds/1342/steps/shell_6/logs/summary
[11:12] <wgrant> I don't know if that was the cause or effect.
[11:13] <jtv> I guess my connection bounced.
[11:13] <jtv> henninge: where does the exception currently go?  We meant to have separate sanitizers for web and import, didn't we?
[11:14] <jelmer_> wgrant: ah, hmm
[11:14] <jtv> henninge: I mean, where does the exception currently go in benji's code?  What catches it?
[11:17] <henninge> jtv: nothing catches it AFAICT
[11:17] <jtv> That would be bad.
[11:17] <henninge> that's my problem with the code ;-)=
[11:18] <henninge> jtv: line 302 of the diff is where it would get raised.
[11:18] <jtv> In fact I'm not even sure this should be an error instead of a warning.
[11:18] <gmb> bigjools: Can you give https://answers.launchpad.net/launchpad/+question/169630 a decent canonical answer? maxb has already answered it but there seems to be some confusion.
[11:19] <henninge> jtv: well, at least the importer has self.errors to which it should be added instead of halting the whole import by raisingn an exception.
[11:19] <bigjools> gmb: I can look
[11:19] <gmb> bigjools: Thanks.
[11:19] <bigjools> gmb: dear lord some people are thick
[11:20] <maxb> Oh that one. I started ignoring it because the user seemed lacking in clue
[11:20] <jtv> henninge: absolutely.  There are cases where a bad newline will confuse things, but I don't see how they could lead to accidental acceptance of the import or anything disastrous like that.  So the parsing at least can proceed.
[11:20] <gmb> Ah. I figured that might be the case, but I'm sufficiently clueless myself that I couldn't actually tell for certain.
[11:20] <wgrant> maxb: But they seem to maintain a package in Debian.
[11:20] <henninge> jtv: for that reason, the introduction of an uncaught exception in the importer code, I'd like to not have this revision deployed.
[11:20] <wgrant> maxb: Which is a worry.
[11:20] <maxb> Yes. Quite.
[11:21] <jtv> henninge: agreed.  How did it get through Q/A?
[11:21] <wgrant> This *is* QA.
[11:21] <henninge> jtv: We are doing it atm. ;-)
[11:21] <jtv> Ah OK
[11:21] <henninge> wgrant: rollback, sorry.
[11:21] <jtv> This is pre-imp stuff.
[11:21] <henninge> yup, and that was lacking here.
[11:21] <jtv> But it's hard to know that at pre-imp time.
[11:22] <jtv> Good thing you caught it.
[11:23] <henninge> wgrant, jtv: can either of you please prepare the rollback branch? I cannot do that at this computer atm, I have to relocate to the office first which will still be a while.
[11:23] <jtv> henninge: I'm not in a position to do that I'm afraid, and wgrant is even further past EOD than I am.  :/
[11:23] <henninge> oh, right.
[11:23] <bigjools> I finished my QA
[11:24] <StevenK> henninge: Mark the bug as qa-bad bad-commit-13889
[11:24] <StevenK> I think it's bad-commit-XXXXX
[11:25] <henninge> I think so, too.
[11:25] <henninge> StevenK: done.
[11:28] <stub> StevenK: You are handling the rollback?
[11:28] <henninge> StevenK: will you do the rollback?
[11:28] <wgrant> I'm on my freshly reinstalled laptop which has no keys at the moment.
[11:28] <henninge> ;)
[11:28] <wgrant> So I'm afraid I can't help.
[11:29] <wgrant> buildbot is ready and waiting for the rollback, however :)
[11:29] <StevenK> Yeah, alright.
[11:29] <henninge> StevenK: thank you!
[11:29] <StevenK> wgrant: Give me the bzr command, since I'm lazy and waiting for rf?
[11:30] <wgrant> bzr merge -r1234..1233 .?
[11:30] <StevenK> Right
[11:30] <StevenK> I tend to do bzr di | patch -p0 -R which is a little disgusting
[11:30] <wgrant> That's very CVS.
[11:31] <StevenK> Guess where I learnt revision control ...
[11:32] <StevenK> henninge: One line description for the rollback?
[11:32] <bigjools> I try not to remember that I learned revision control in CVS
[11:33]  * gmb lunches
[11:34] <henninge> "[rs=henninge][rollback=13889] Rollback r13889 because it introduces an uncaught exception in translation import code."
[11:34] <henninge> StevenK: ^
[11:34] <henninge> like that?
[11:34] <StevenK> Looks good.
[11:34] <cjwatson> I'm pretty sure I originally learned revision control in RCS, which I'm not sure is an improvement
[11:34]  * henninge lunches
[11:36]  * wgrant only seriously learned version control with svn :(
[11:38] <StevenK> henninge-lunch, wgrant, stub: Revert landed.
[11:38] <wgrant> Thanks.
[11:39] <StevenK> Now to wait 11 minutes for buildbot and then 4h20, and then 60 minutes.
[11:39] <StevenK> Then we can think about deploying
[11:40] <bigjools> svn isn't much better
[11:44] <nigelb> I learned bzr, then git, and then svn.
[11:44] <nigelb> Backwards, yeah.
[11:45] <StevenK> CVS, then how to fix broken CVS repos, svn, svk (twitch), tla, baz and then bzr
[11:46] <StevenK> I am allergic to git
[11:46] <nigelb> There are creams for that :P
[11:47] <StevenK> I no longer have a reason to learn it
[11:53] <bigjools> I tried to use git for another OSS project I play with, and found it unfathomable
[11:53] <bigjools> I think it's the colo branches that annoy me the most
[12:04] <wgrant> bigjools: bzr-git :)
[12:04] <bigjools> yes :)
[12:05] <bigjools> does it work properly now? it had some bug that stopped me importing some kinds of git repos
[12:05] <wgrant> The only failures I know of now are lack of submodule support and lack of support for backslashes in paths.
[12:06] <nigelb> bigjools: I kinda like colo branches :)
[12:07] <bigjools> nigelb: in some cases yes, I use a colo checkout in bzr but I just found the git interface to them confusing.  Having said that, I found bzr rather confusing initially too.
[12:07] <bigjools> The help text has a nasty habit of defining some of bzr commands using the same word in the definition.
[12:09] <nigelb> bigjools: I use a zsh extension to lessen the confusion of git branches
[12:10] <bigjools> you use *zsh* to *lessen* confusion?
[12:10] <bigjools> IRONY KLAXON!
[12:16] <nigelb> heh
[12:16] <nigelb> zsh is nice when you use oh-my-zsh
[12:59] <gary_poster> stub, hi you still around?
[13:02] <gary_poster> nm stub, thanks
[13:17] <stub> gary_poster: yo
[13:18] <gary_poster> hey stub, I have a corrupted postgres that won't start after a hard drive incident (PANIC:  could not locate a valid checkpoint record) and was wondering if there were a quick way to wipe it away
[13:18] <gary_poster> and start again
[13:18] <gary_poster> I decided to go ahead with some overdue upgrade work and restart, but if there is a quick answer, that would be cool
[13:19] <stub> gary_poster: Its /var/lib/postgresql/8.4/main
[13:19] <wgrant> utilities/launchpad-database-setup should do it, too.
[13:19] <wgrant> It drops the cluster and is OK at recovering from completely broken setups.
[13:19] <stub> even better as then we don't need to recover the config
[13:19] <gary_poster> ah-ha, cool thanks wgrant and stub, will give it a try
[13:21] <gary_poster> yes, worked a charm.  thanks again
[13:28] <sinzui> jcsackett, do you have time to mumble?
[13:29] <wgrant> gary_poster: We should be able to deploy r13891 in about 4.5 hours. Will someone from your squad be able to arrange that?
[13:29] <wgrant> gary_poster: QA is done; all that's left is one rollback revision that's currently in buildbot.
[13:29] <gary_poster> yes, wgrant, we'll do it.
[13:30] <wgrant> Thanks!
[13:31] <wgrant> gary_poster: buildbot has been a little unreliable lately: if this test run fails, get a LOSA to check for and kill any orphaned processes on pigeonpea. bzr forking services and rabbitmqs have been leaking occasionally.
[13:31] <wgrant> I sorted most of the flaky tests on Monday, but there still seems to one somewhere doing nasty stuff.
[13:32] <gary_poster> wgrant, :-/ ok thanks for warning.  I saw the Monday cleanups, yes
[13:32] <wgrant> So we just have to remember to clean the slaves every so often for now :/
[13:32] <mthaddon> I'd rather we figured out why these processes are hanging around - seems like we've had to do this kind of clean up quite a lot recently
[13:32] <gary_poster> yeah :-/
[13:32] <jcsackett> sinzui: sure, firing up mumble in a moment.
[13:37] <bigjools> wgrant: what's the situation with Rabbit versions and packages?  Your email left me a bit confused,
[13:39] <wgrant> bigjools: I have 2.3.1 of the server and the required plugins packaged for lucid->natty. But 2.3 is getting pretty old now; 2.6 was released a couple of weeks ago. Oneiric has 2.5, so I will need to package plugins for at least 2.5 as well.
[13:39] <wgrant> So I'm not sure if we want to go to 2.5 everywhere, or even 2.6, depending on when this work is going to happen.
[13:40] <bigjools> wgrant: so we need to backport and put it in the lp PPA
[13:40] <bigjools> might as well go for the latest release provided it works on lucid and oneiric/natty
[13:40] <bigjools> wgrant: are you the only one making packages at this point?
[13:41] <wgrant> I think latest is probably best. It's not as if we're upgrading a core part of the system to an non-battletested release.
[13:41] <wgrant> Well, the server packages and plugin infrastructure are maintained in Ubuntu.
[13:41] <bigjools> indeed
[13:41] <wgrant> 2.6 isn't there yet, but I have 2.6 server packages already.
[13:41] <bigjools> I want to avoid a custom package
[13:42] <wgrant> Hopefully we can get the extra plugins into Ubuntu for oneiric+1.
[13:42] <bigjools> yes - which reminds me to send an email
[13:42] <bigjools> what is not there right now that we need?
[13:42] <wgrant> Check https://launchpad.net/~wgrant/+archive/rabbitmq
[13:43] <wgrant> rabbitmq-server and rabbitmq-erlang-client are straight backports of natty versions.
[13:43] <bigjools> what about the management plugin?
[13:44] <wgrant> rabbitmq-management depends on mochiweb, webmachine, rabbitmq-mochiweb and rabbitmq-management-agent.
[13:44] <wgrant> None of those are in Ubuntu.
[13:44] <bigjools> ok ta
[13:44] <bigjools> are they in Debian?
[13:44] <wgrant> mochiweb/webmachine are general Erlang libs, not rabbit-specific.
[13:44] <bigjools> as in, packaged, or did you package?
[13:44] <wgrant> They weren't two months ago when I packaged them initially, but that may have changed.
[13:44] <wgrant> I packaged them.
[13:45] <bigjools> arse
[13:45] <wgrant> Not that there was much to it.
[13:45] <bigjools> ok
[13:45] <wgrant> But yes.
[13:45] <wgrant> eg. for mochiweb: https://launchpadlibrarian.net/74782554/mochiweb_1.5.2-0ppa1.diff.gz
[13:45] <bigjools> what is rabbitmq-erlang-client  for?
[13:46] <wgrant> It's a rabbitmq client for erlang.
[13:46] <bigjools> no shit sherlock :)
[13:46] <wgrant> Some of the other plugins speak AMQP using it.
[13:46] <wgrant> It *is* in Debian and Ubuntu, I believe.
[13:46] <bigjools> I was wondering what needs it since it wasn't mentioned in your dep list above
[13:47] <wgrant> I think management-agent depends on it.
[13:47] <wgrant> It's in Ubuntu, but not Debian.
[13:47] <bigjools> ok
[13:47] <allenap> abentley: Hi. Line 45 in https://code.launchpad.net/~allenap/storm/json-property/+merge/74428 looks a bit like a manifestation of bug 510052, but I can't figure out what I did wrong. Could you help me out?
[13:47] <_mup_> Bug #510052: Incorrect Merged proposal diff produced with pre-requisite option <code-review> <lp-code> <udd> <Launchpad itself:Invalid> <Ubuntu Distributed Development:Invalid> < https://launchpad.net/bugs/510052 >
[13:48] <wgrant> rabbitmq-management and rabbitmq-management-agent both depend on rabbitmq-erlang-client
[13:48] <bigjools> coolio, thanks
[13:48] <bigjools> so we need the lot
[13:48] <wgrant> And the packages are all pretty trivial.
[13:48] <abentley> allenap: if it is a manifestation of bug 510052, then there's nothing you did wrong.
[13:48] <_mup_> Bug #510052: Incorrect Merged proposal diff produced with pre-requisite option <code-review> <lp-code> <udd> <Launchpad itself:Invalid> <Ubuntu Distributed Development:Invalid> < https://launchpad.net/bugs/510052 >
[13:50] <allenap> abentley: Bug 510052 is marked Invalid, so I wondered if I had actually done something wrong instead, Occam's Razor and all that.
[13:50] <_mup_> Bug #510052: Incorrect Merged proposal diff produced with pre-requisite option <code-review> <lp-code> <udd> <Launchpad itself:Invalid> <Ubuntu Distributed Development:Invalid> < https://launchpad.net/bugs/510052 >
[13:52] <abentley> allenap: There is a legitimate bug where incorrect diffs are produced, but it's fairly rare.
[13:52] <wgrant> sinzui: Ah, I'm glad it was not just me who ran your suggested test case blindly!
[13:53] <abentley> allenap: So, I merged jkakar's branch into lp:storm, and it produced the conflict you see.
[13:55] <allenap> abentley: My branch merges trunk and resolves those conflicts. Should I have started from trunk and merged Jamu's branch instead?
[13:56] <bac> abentley: i have made the change to combine DerivedAuthorization and ForwardedAuthorization.  i chose a new name DelegatedAuthorization, which i think is more descriptive.  you can see the diff at http://pastebin.ubuntu.com/684417/
[13:56] <bigjools> Delegated makes me think of lazr.delegates
[13:57] <bigjools> or whatever it is
[13:57] <bac> i considered that but they are different beasts
[13:58] <bigjools> I think your original name was the best!
[13:59] <abentley> allenap: yes, you would have needed to fix the conflicts in Jamu's branch.  I think the conflict removal is shown because that's one of the differences between your branch and Jamu's.
[14:00] <allenap> abentley: Okay, cheers.
[14:02] <abentley> allenap: Looks good.  I expect we'll want to support different permissions per object at some point, but we can cross that bridge when we get to it.
[14:03] <allenap> abentley: Was that meant for someone else?
[14:03] <bac> allenap i think that was for me
[14:03] <abentley> bac: Looks good.  I expect we'll want to support different permissions per object at some point, but we can cross that bridge when we get to it.
[14:03] <abentley> allenap: yep, thanks.
[14:03] <bac> thanks abentley
[14:07] <jkakar> allenap, abentley: Hi! :)
[14:08] <abentley> jkakar: hi.
[14:08] <jkakar> allenap: Thanks for picking up my branch and finishing it off.
[14:08] <jkakar> allenap: Should I just merge it into my branch and get therve to approve it, so I can land it?
[14:09] <allenap> jkakar: No worries, it was nice to see that what I was thinking of was already there :) And sure, that would be great.
[14:09] <jelmer_> has something changed in the handling of merge proposals recently? They seem to be timing out more often than previously, even on a project like bzr
[14:09] <allenap> jkakar: Fwiw, the diff in my merge proposal is now free of conflict markers, so you can see what you're getting easily.
[14:10] <allenap> jkakar: Garg, no it's not. Ignore me :)
[14:10] <jkakar> allenap: Heh
[14:10] <jkakar> allenap: Okay, I'll merge it into my branch and harass therve. :)
[14:10] <allenap> Awesome, ta :)
[14:13] <bigjools> wgrant: I need to specify which rabbit package versions we want in oneiric+1.  AFAIK we don't *need* the latest and you packaged 2.3.1 but I suspect they'll just take whatever you packaged.
[14:13] <bigjools> any preferences?
[14:16] <wgrant> bigjools: What I have already can't go into oneiric+1, since it's lower than what oneiric has.
[14:16] <bigjools> ha
[14:17] <wgrant> And releasing the LTS with a very old RabbitMQ would be foolish.
[14:17] <bigjools> well, yes
[14:17] <wgrant> I suspect oneiric+1 will end up going with whatever Debian has at the time, but maybe not.
[14:27] <fjlacoste> bigjools: did you get a volunteer yet?
[14:27] <bigjools> fjlacoste: OTP, but no
[14:35] <jkakar> allenap: The branch is merged, thanks!
[14:35] <allenap> jkakar: \o/
[14:43] <allenap> stub: I have an update to lp:~launchpad-committers/storm/with-without-datetime. What do I do next? My guess: (1) push with with-without-datetime, (2) build egg (how?), (3) put egg tarball in lp:~launchpad/lp-source-dependencies/trunk, (4) update versions.cfg in Launchpad.
[14:46] <stub> Yes, 1) update lp:~launchpad-committers/storm/with-without-datetime 2) python setup.py egg_info -b-lpwithnodatetime-rXXX sdist
[14:47] <stub> Twiddle the -b option until the generated filename is correct
[14:47] <stub> and the rest you know
[14:48] <allenap> stub: Brilliant, thank you.
[15:44] <adeuring> abentley: fancy a review of a not-too-big diff? https://code.launchpad.net/~adeuring/lazr.batchnavigator/lazr.batchnavigator-result-length-from-range-factory/+merge/74459
[15:44] <abentley> adeuring: sure.
[15:45] <adeuring> thanks!
[15:45] <bac> abentley: can you do a review at your leisure?  https://code.launchpad.net/~bac/launchpad/bug-838957/+merge/74460
[15:46] <abentley> bac: sure.
[15:48] <abentley> adeuring: "should" misspelled on 29.
[15:48] <adeuring> abentley: right. fixed locally.
[15:49] <adeuring> ...and line 30 has a typo too...
[15:51] <abentley> adeuring: What do you think about saying "rough_length" or "approx_length" or something instead of "result_length"?
[15:52] <adeuring> abentley: good idea! let's use rough_length
[15:53] <abentley> adeuring: r=me
[15:53] <adeuring> abentley: cool, thanks!
[15:57] <abentley> bac: I think we're recommending catching exceptions using the "as" syntax, e.g. "except ValueError as e"
[15:58] <stub> adeuring: You found estimateRowCount in lib/canonical/database/postgresql.py ?
[15:58] <adeuring> stub: not yet; thanks for the hint! will make work on my next branch easier :)
[15:59] <bac> abentley: good catch.  i haven't gotten into that habit yet
[15:59] <stub> adeuring: Feel free to drop that function and create something more useful with Storm. I don't think there are any callsites.
[15:59] <abentley> bac: r=me
[15:59] <bac> tx
[15:59] <bac> er, thanks
[15:59] <adeuring> stub: ok, I'll check it
[16:04] <abentley> gmb: I think your code could be tested using MockIo.  Have you taken a look at that?
[16:05] <gmb> abentley: Ah, ISWYM. No, I hadn't thought of that - been too wrapped up in getting the damn thing working. I'll do that now, thanks for the suggestion.
[16:05] <abentley> gmb: no problem.
[16:06] <abentley> gmb: Even when we get those integration testing facilities, we should avoid using them where we're not actually testing integration.
[16:06] <gmb> Fair enough.
[16:51] <nigelb> jelmer_: could you /nick to jelmer?
[16:51] <nigelb> Classbot is complaining that you're around
[16:51] <nigelb> :)
[16:52] <nigelb> And you can /join #ubuntu-classroom-backstage in case you need to poke us for help :)
[17:23] <nigelb> can I tag a bug that's  fixed again if I'm improving the fix?
[17:41] <sinzui> nigelb, we do not have a tag for that. It is best to report a new bug and add a comment to the old bug that you are working on an improvement
[17:41] <nigelb> sinzui: excellent, ok
[17:41] <sinzui> nigelb, I believe we will have bug linking by the end of the year
[17:41] <nigelb> its the fonts bug. Needs a bit more tweaking
[17:42] <sinzui> I saw William's remarks. Your branch did fix the bug
[17:42] <nigelb> ok,I'll open a new one and assign it to me
[17:42] <sinzui> I was tempted to comment that most of the uses of italics in Launchpad are incorrect. They should be strong instead of em
[17:55] <jelmer> hi sinzui
[17:55] <sinzui> hi jelmer
[17:56] <jelmer> sidnei: saw your gtk3 branch for bzr-gtk, thanks for that. I'll see if I can have time to do a review of it in the next couple of days.
[17:56] <sinzui> thank you
[17:56] <jelmer> grarr. lolcats are messin with mai englishz
[17:56] <jelmer> s/can have/have/
[18:18] <nigelb> How hard is it to fix bug 88545?
[18:18] <_mup_> Bug #88545: Abolish the "statusexplanation" database field <lp-bugs> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/88545 >
[18:25] <nigelb> abentley: Hi, could you do a quick review? (its a tiny diff) https://code.launchpad.net/~nigelbabu/launchpad/font-fixes-787798/+merge/74492
[18:29] <abentley> nigelb: certainly.
[18:31] <abentley> nigelb: r=me.  What's it doing exactly?  It looks like it's specifying normal, italic, bold, bold-italic.
[18:31] <nigelb> Is including that woff from google web fonts
[18:31] <nigelb> .woff
[19:17] <abentley> lifeless: just ran the first concurrent test-farm run.
[19:20] <nigelb> what does bug-columns tag mean?
[19:32] <stub> abentley: \o/
[19:32] <lifeless> abentley: cool!
[19:33]  * abentley may need to change the name of this project, because Spinal Tap's "Sex Farm" keeps going around in his head.
[19:35] <nigelb> haha
[19:41] <stub> http://pgfoundry.org/pipermail/pgbouncer-general/2011-September/000851.html
[19:41] <stub> Its hyphenated database name day
[19:56] <nigelb> Is the team leads meeting notes new?
[19:56] <nigelb> I've never seen it on the dev list before.
[20:32] <sinzui> nigelb, They are not new. I believe they were sent to the wrong list :)
[20:40] <nigelb> sinzui: aww, drat. I enjoyed reading them :)
[20:51] <benji> abentley: do you have the time/inclination to do a lazr.restful review (it's really simple)? https://code.launchpad.net/~benji/lazr.restful/do-not-hide-original-tracebacks/+merge/74516
[20:53] <abentley> benji: r=me, and this is a bug that I reported.  Thanks!
[20:54] <benji> abentley: cool, I'll find the bug report so I can decorate it appropriately
[20:54] <abentley> benji: I believe it's bug 832136
[20:54] <_mup_> Bug #832136: tracebacks are obfuscated <lazr.restful:Triaged> < https://launchpad.net/bugs/832136 >
[20:54] <benji> cool, thanks
[23:07] <sinzui> wallyworld_, wgrant, stevenK: I think mumble does not want me to attend the standup
[23:07] <wgrant> sinzui: We were able to hear you.
[23:07] <wgrant> Both the first and second times.
[23:53] <jelmer> sigh, I now seem to have traded in my password error for another error when trying to run the launchpad tests
[23:55] <jelmer> 	psycopg2.OperationalError: terminating connection due to administrator command
[23:55] <jelmer> 	SSL connection has been closed unexpectedly
[23:55] <jelmer> does that look familiar to anybody?