[00:15] bac [00:15] *back* [00:15] (sorry bac) [00:16] lifeless: Haha, I did wonder if you were at your keys or wanted Brad's attention === lifeless changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 240 - 0:[#######=]:256 === wgrant changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: wgrant | Critical bugs: 241 - 0:[#######=]:256 [00:32] Anyone around to review https://code.launchpad.net/~wgrant/launchpad/iseriesbugtarget/+merge/69951? [01:08] lifeless: You don't have a good suggestion for a primary bug target? [01:09] ie. product/distro/DSP? [01:09] wgrant: 'thing', 'target', 'context', shrug. [01:10] wgrant: I think we want to remove the series special casing eventually, so I don't really care about the name. [01:10] True. [01:45] lifeless: following on from last week, could you please look at this mp (and +1 if you are happy). then i will land it for the contributor https://code.launchpad.net/~xaav/loggerhead/export-tarball/+merge/66408 [01:58] * 9967 Exceptions [01:58] Hi codehosting. [01:58] \o/ [02:08] hi wallyworld [02:09] poolie: hi [02:09] thanks for pushing it [02:09] np [02:10] i got caught up yesterday === jtv-zzz is now known as jtv [02:47] StevenK, wgrant: I uploaded a package to -partner (on dogfood) and ran publish-ftpmaster. The pool now contains the .dsc and 2×tarball, and the package is in the Sources list, but it's not showing up in the Packages files and I don't see a .deb. Is that bad? [02:47] Has it built? [02:48] And 2*tarball? [02:48] Needs build + potential acceptance [02:48] StevenK: orig.tar.gz and debian.tar.gz [02:48] How do I find out about build and potential acceptance? [02:49] What does dogfood.l.n/builders say? [02:49] 2 builders: ferraz & rubidium, both idle [02:50] Haven't found my package ("bye") in the logs yet, but the package I based it on ("hello") failed to build. [02:51] chroot problem. [02:52] Ah, "bye" built successfully on ferraz. [02:52] It probably ended up in NEW. [02:53] Yep, there it is. [02:53] https://dogfood.launchpad.net/ubuntu/oneiric/+queue [02:53] The source package page also fails to show a deb. [02:53] It doesn't really exist yet. [02:53] https://dogfood.launchpad.net/ubuntu/+source/bye/1.0 [02:54] So… do I need to approve the binary upload like I did the source upload? [02:54] Yes. [02:54] On the way. [02:54] There we go. [02:55] And now… process-accepted? [02:55] publish-ftpmaster should do that, right? [02:55] You have me there. Checking. [02:55] Yup, it does. [02:56] So then I can just re-run publish-ftpmaster? [02:56] Correct. [02:59] It's mentioning the package now: "(Arch Specific)" [02:59] I don't know who Arch Specific is, but he seems to be doing something to my package. [03:01] "arch specific" means "not architecture independent" [03:05] wgrant: to be really, really honest I did sort of gather it would be something like that. :) [03:06] Anyway, it's done now. Which seems suspiciously quick. [03:06] Then again, there won't have been any changes outside of -partner. [03:06] And partner is both NMAF and small. [03:08] NMAF? [03:08] No More Apt-Ftparchive [03:09] Ah, you mean it uses Launchpad's indexing code? [03:09] Well, all green lights so far. [03:09] Right. [03:09] My package is in Packages for i386, and the +source page shows the i386 build. [03:09] Excellent. [03:09] And it didn't delete 600GB of archive? [03:10] Errr [03:11] lifeless: fix all of my problems! [03:11] :) [03:11] wgrant: the ubuntu-archive dir now contains about 15GB, I think. [03:12] hey all - the new launchpad haproxy stuff is killing me [03:12] I may lose power. [03:12] mtaylor: Oh? [03:12] jtv: Sounds good. [03:12] wgrant: it's causing tarmac to have its connections disconnected [03:12] mtaylor: It maintains persistent connections? [03:12] wgrant: which is problematic [03:12] wgrant: it ddoes [03:12] It probably shouldn't. [03:13] It didn't have long-term connections open yesterday, interestingly... [03:13] wgrant: well, according to abently, bzrlib expects to stay connected for some reason [03:13] wgrant: the biggest chunks being in contents-generationold. About 2GB in /srv/launchpad.net/ubuntu-archive/ubuntu/pool. [03:13] mtaylor: I suspect you want to change your plugin to manage transports a little better. [03:13] mtaylor: It can't expect to remain connected for weeks. [03:13] wgrant: it doesn't [03:13] wgrant: surprisingly, almost the same amount of data in ubuntu-partner. [03:14] wgrant: it just stays connected while it runs tests [03:14] Ah. [03:14] Someone else is keeping connections open for weeks, so I thought you might be too. [03:14] wgrant: which sometimes is longer than 50s [03:14] nope. that shouldn't be us [03:14] So, sounds like your plugin needs to be fixed to not do that. [03:15] We can possibly increase the haproxy timeouts for now, if it is causing big problems for you. [03:15] But only very temporarily. [03:15] wgrant: rockstar told me to come bug you :) --- and it's actually the core tarmac code [03:15] tarmac holds the connection around the post-merge hook [03:15] Hmm. [03:16] rockstar: Any reason Tarmac can't handle transports a bit more sensibly? [03:19] wgrant: https://jenkins.openstack.org/view/Nova/job/nova-tarmac/109487/console [03:20] or more excitingly: https://jenkins.openstack.org/view/Nova/job/nova-tarmac/109467/console [03:20] That's rather unpleasant. [03:22] mtaylor: Use the source monty! [03:22] lifeless: these are not the droids you are looking for [03:25] mtaylor: wgrant: so, this is a bzrlib bug. [03:25] :( no criticals in that rollout [03:25] not the holding open [03:25] the handling of the disconnects. [03:25] transports are defined stateless. [03:25] so are RPC calls. [03:26] lifeless: yay! nothing better than a bzrlib bug! [03:26] so the bug is 'when an idle ssh transport is disconnected, bzrlib should not error' [03:26] or [03:26] 'when an idle ssh transport is interrupted, bzrlib errors' [03:27] the haproxy stuff is showing this up very visibly, but the bug pre-existed - bzr didn't seen keepalives, and if ssh wasn't configured to do so it could naturally happen anyhow [03:27] however, lets up it for now to 10 minutes. [03:28] * mtaylor filing bzr bug [03:30] bug 819604 [03:30] <_mup_> Bug #819604: when an idle ssh transport is interrupted, bzrlib errors < https://launchpad.net/bugs/819604 > [03:32] lifeless: you gonna be at the next uds? [03:33] no [03:33] new sprog (we hope) [03:34] what's a sprog? [03:34] child [03:34] OH! [03:35] well, in that case, coming to UDS would be the wrong choice [03:35] (and hopefully congrats) [03:35] yes, we think so [03:35] LCA then? [03:35] doubtful [03:35] gah. I'm starting to think you're avoiding hanging out with me :) [03:35] thats it, totally. [03:36] if you wanted to swing by christchurch after UDS we could put you up for a few days [03:36] bah [03:36] LCA [03:36] ooh. now _that's_ not a bad idea [03:36] and yeah - I read LCA there [03:36] I still haven't been to the south island [03:36] thinking about hanging out with Stewart for a while pre-LCA [03:36] speaking of - I REALLY need to submit talk proposal... [03:37] UDS +1 I expect I will be at [03:41] yay! [03:41] * mtaylor lists UDS's and LCA as the important things he should attend [03:55] So, recently I used vagrant. [03:55] I'm wondering how easy it would be to create a vagrant file to set up LP environement. [03:56] wgrant: I think partner publication works. Next up is expedited -security publishing. For that I need to copy a package into security, right? [04:06] wgrant, the reason is because bzr doesn't handle transports more sensibly? [04:08] I keep hearing launchpad people pushing back on this, and I understand why, but tarmac pushes as much as it can off to bzr. [04:09] I'm unsure why we're timing out so quickly now. [04:11] * rockstar sees that lifeless has already covered this, and goes to bed [04:17] jtv: Right. [04:17] jtv: You can copy from a public PPA, if you want. [04:17] Thanks. [04:20] Edit before sending? [y/n]: yConnection to bazaar.launchpad.net closed by remote host. [04:20] Heh [04:21] wgrant: Ouch [04:48] StevenK: hi [04:48] StevenK: https://code.launchpad.net/~stevenk/launchpad/pillarname-vocab/+merge/70091 [04:48] StevenK: vocabs depend on stable ordering to paginate [04:50] It is stable? [04:50] ho ? [04:50] how? [04:51] It appeared to be when I tested it on DF [04:51] its not stable with an order by rank, when two rows can have the same rank [04:52] you either need a more granular rank, or a disambiguator [04:52] Right, then I want rank first and name second [04:52] orderBy='rank- name' ? [04:53] for storm? order_by=(SQL('rank'), PillarName.name) [04:53] Desc(SQL('rank')), PillarName.name [04:53] only if you want it to work [05:03] lifeless: It will fail to land anyway, so I'll fix it once I'm sure no other tests have failed [05:04] cool [05:04] sorry for having to raise this [05:05] I should have thought of it, by rights [05:06] :) [05:27] Project devel build #937: STILL FAILING in 5 hr 40 min: https://lpci.wedontsleep.org/job/devel/937/ [06:07] wgrant: fun stuff for oneiric : https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/819621 [06:07] <_mup_> Bug #819621: lucid container start failure after calling lxc-stop (fails across reboots) < https://launchpad.net/bugs/819621 > [06:10] lifeless: I noticed that too, but decided it was probably the avahi or similar that I had installed. [06:10] Upsetting to hear that it happens even when the container is not terribly mangled. [06:10] (avahi sets odd rlimits for itself, which mean more than one instance can't run on a single kernel without a bit of work) [06:11] nproc == 2, what could possibly go wrong. [06:11] also having plymouth in the container is just bong [06:12] Mmm. [06:12] Not necessarily. [06:12] It's not just a splash these days. [06:12] It's the way upstart communicates with the outside world. [06:30] jtv: Are you still playing in dogfood's wading pool? [07:03] Bloody *hell* (Error ID: OOPS-2040DOGFOOD18397) [07:03] How has DF generated 18,000 OOPSes? [07:04] Probably the a-f warnings. [07:06] And the publisher is running, so the webapp is being horridly slow. [07:07] :D [07:08] It can't even load bugs.dogfood.l.n [07:17] wallyworld: Hmm, so the question subscription stuff is based on the *old* Bugs stuff? [07:17] no, how did you think that? [07:17] "Direct subscribers" and "Also notified" [07:18] Old, but more sensible, terms. [07:18] that's how questions subscriptions have always worked. i just made it use ajax [07:18] instead of html forms [07:18] so i extended the new subscribers_list portlet [07:18] Right. [07:19] so, you ok with the change? [07:19] StevenK: still running [07:19] wallyworld: Would be nice if we eventually integrated the same self-subscription stuff that Bugs introduced, but small steps. [07:20] wgrant: yes, one thing at a time. it's now much better than it was last week. it's now possible to unsubscribe without SQL :-) [07:20] Yup. [07:22] * wallyworld off to soccer [07:29] good morning [07:59] Good morning/evening wgrant :) Got time for a very short review? https://code.launchpad.net/~allenap/launchpad/dsd-base-view-dont-modify-globals-bug-809985/+merge/70076 [08:01] allenap: that's rather evil, but OK! [08:01] Approved. === wgrant changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 241 - 0:[#######=]:256 [08:02] wgrant: Thanks :) [08:09] g'morning [08:19] Morning === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [08:43] Morning jelmer :) [08:44] jelmer: I saw that Dulwich made the front page of Hacker News. [08:50] allenap: yeah :) [08:55] allenap: I've met the Google code folks and have been in contact with them. They've contributed a bunch of patches which should help with performance. [08:55] jelmer: Also, bug 808035 is at the top of the deploy queue and needs testing :) [08:55] <_mup_> Bug #808035: AttributeError: 'NoneType' object has no attribute 'write' during git import

< https://launchpad.net/bugs/808035 > [08:55] That should also have a significant impact on git code import performance. [08:55] allenap: Yep, it's on the top of my todo list too. [08:55] jelmer: That's really cool :) [08:56] adeuring: hiya [09:04] mrevell, hi, do you have any time today to help move the docs forward and potentially announce the change to maintainers by email (import queue stuff)? [09:05] danilos, Yes, certainly. In 30 minutes. [09:05] mrevell, excellent, let's talk then [09:10] hi lifeless [09:12] adeuring: https://code.launchpad.net/~adeuring/launchpad/bug-739052/+merge/69625 - you're not landing it yet ? [I can't see the column issue addressed] [09:12] lifeless: now running through ec2 [09:13] forgot that yesterday... [09:13] adeuring: and there were a bunch of suggestions that seem forgotten too :( [09:13] I'm also working on the remaining suggestions you made [09:14] adeuring: oh cool! - are you thinking of two separate landings ? [09:14] lifeless: actually, three, to keep the diffs to review small [09:14] sure thing; I'd be delighted to review those for you [09:14] adeuring: have I mentioned how glad I am that you're doing this. [09:15] lifeless: too late for this one : https://code.launchpad.net/~adeuring/launchpad/bug-739052-2/+merge/70044 ;) [09:15] lifeless: and thanks :) [09:16] (sorry, I have some reaally long lag between typing IRC messages and looking at incoimng...) [09:16] heh no worries [09:18] adeuring: so why won't (col1 >= M1 and col2 >= M2 and colN >MN) work ? [09:19] oh, I see [09:21] adeuring: however, using a tuple will work, I think ? [09:21] hmmm, only if the direction on all the columns is consistent [09:22] lifeless: no, I think we need, for three sort columns: [09:22] col1 == memo1, col2 == memo2, col3 > memo3, then... [09:22] col1 == memo1, col2 > memo2 [09:22] then col1 > memo1 [09:22] adeuring: what about [09:23] (col1, col2, col3) >= (memo1, memo2, memo3) [09:23] that wouldn't change much [09:23] problem is: [09:23] when the value in col1 increases, the values in col2, col3... starting from the minimum [09:24] so we end up with N conditions for N sort columns [09:26] lifeless: I think we have at least three options to "join" these N conditions: a more or less huge OR (implemented for mow), or a UNION ALL on sub-selects for each conditions [09:26] or [09:26] we can iterate in Python over the conditions [09:26] adeuring: if the direction is consistent, a tuple works [09:27] lifeless: ah, right! [09:27] http://pastebin.com/mcShr1D2 [09:27] lifeless: but how do we express this in SQL? [09:27] just so [09:27] lifeless: cool! [09:28] so, the content of my next branch is obvious ;) [09:28] :) [09:28] we may have a lot where we can't do this [09:28] but we can probably group all the adjacent same-direction columns anyhow [09:29] lifeless: right [09:33] jml: Hi! ;) [09:34] henninge: hi [09:34] jml: I got a failed ec2 run for your branch. [09:34] henninge: me too, but no actual failures [09:34] jml: right [09:34] it's the "smtp message exeeds size limit" [09:35] jml: same for you? [09:35] henninge: I've corrected the default value as per StevenK's comments. I suspect that would have caused some tests to fail. [09:35] henninge: yes. [09:35] that smtp error means a catastrophic failure [09:35] lifeless: you mean "too many failures, the mail gets too big" ? [09:35] yes [09:38] jml: I see you pushed, shall I start the landing again? [09:38] henninge: yes. thank you. [09:38] ok [11:03] allenap: there is a feature flag you can use for profiling too [11:03] allenap: the default profile dir is $cwd, I think. [11:05] lifeless: Oh neat. I was just shuffling my wiki notes; I think that one is from back in the days when BjornT_ ran the bugs team :) Not sure if it'll even work any more. [11:09] Any reviewers in the house? → https://code.launchpad.net/~jtv/launchpad/bug-819674/+merge/70135 [11:11] who actually uses checkUpload via the API? [11:12] Project devel build #938: STILL FAILING in 5 hr 44 min: https://lpci.wedontsleep.org/job/devel/938/ [11:12] jml: I would imagine things like request-sync [11:12] jml: to do things like determine if the current user requires sponsorship [11:13] jelmer: ah, yeah, that would be a thing. [11:13] for checking PPA uploads, it's not particularly useful [11:14] since it errors when it doesn't recognize the source package, and insists that you supply component & pocket [11:15] yeah, it's a bit odd === jtv is now known as jtv-afk [11:38] night all [11:38] g'night lifeless [11:38] jtv-afk: trade you for https://code.launchpad.net/~jelmer/launchpad/logginguifactory-fixes/+merge/70144 ? [12:14] The publisher takes 4+ hours on DF? Srsly? === matsubara-afk is now known as matsubara [13:08] StevenK: it sometimes does === mrevell__ is now known as mrevell [13:59] adeuring: Is it considered a feature that https://bugs.launchpad.net/mahara/+bug/630891%20/+index works? [13:59] <_mup_> Bug #630891: Unable to delete Notification messages < https://launchpad.net/bugs/630891 > [13:59] adeuring: i.e. a URL with whitespace in it? [13:59] abentley: I have no idea... [14:00] adeuring: It seems bizarre, and it means that https://bugs.launchpad.net/mahara/+bug/630891%C2%A0/+index fails due to encoding issues. [14:00] <_mup_> Bug #630891: Unable to delete Notification messages < https://launchpad.net/bugs/630891 > [14:01] abentley: I don't see how these two URL-oddities are related [14:02] adeuring: If URLs with spurious characters were not permitted, the second would give a LocationError instead of trying, and failing to render. [14:02] adeuring: i.e. a "Not found"/ "Lost something"? [14:03] abentley: sure, a "not found" would be more reasonable, but the failure for your second URL is a separate issue: A unidoce decoding problem [14:04] abentley: we would get that too for a project name like "mülltüte" [14:04] but such names a not allowed [14:04] adeuring: Our URLs don't have non-ascii characters, so they can't have a unicode decoding problem. [14:04] adeuring: Except bug URLs, which can have spurious non-ascii characters. [14:05] abentley: do we have a referer for the \xa0 / %C2%A0 URL? [14:05] abentley: I mean: you can always type URLs manually [14:06] adeuring: No, but it was googlebot. [14:08] abentley: so the URL has been somewhere/somehow generated. So we have two issues: the unicode error, and the fact that a spurious space at least in bug URLs does not result in a 404 [14:09] adeuring: Yes, that's my view. It hardly seems worth fixing the encoding bug if non-ascii URLs are supposed to be verboten. [14:09] adeuring: Who knows what other bugs non-ascii URLs might reveal? [14:10] abentley: yeah,,, [14:10] abentley: but regarding the working URL with the %20: [14:10] Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53) [14:10] [GCC 4.5.2] on linux2 [14:10] Type "help", "copyright", "credits" or "license" for more information. [14:10] >>> int('1') [14:10] 1 [14:10] >>> int('1 ') [14:10] 1 [14:12] abentley: I guess that the travesal code does just such a simple int('630891 ') [14:12] adeuring: Interestingly: ValueError: invalid literal for int() with base 10: '2\xa0' [14:13] abentley: try int(u'1\xa0') [14:16] adeuring: Fascinating. So that is only permitted for unicode strings, because only in unicode strings does \xa0 refer to the same codepoint consistently. [14:19] abentley: doesn't the "can't encode character u'\xa0'" in the traceback indicate that dict['PATH_INFO'] already _is_ a unicode object? [14:21] adeuring: yes, that's what I think. [14:22] abentley: so again not a "clear border" where 8-bit sequences with some encoding are supposed to live on one side and unicode objects on the other... [14:24] adeuring: Right. Requests appear to use a "sane_environment" where values are unicode, but converting the browser request to a web service request appears to re-convert the environment. [14:25] abentley: so.... a trvial but bad workaround would be to convert to utf-8 in this case. [14:26] adeuring: Might be a necessary workaround, depending on how these calls are structured. [14:27] abentley: if you want more fun, try this URL: https://bugs.launchpad.net/mahara/+bug/630891%C3%A4/+index [14:27] <_mup_> Bug #630891: Unable to delete Notification messages < https://launchpad.net/bugs/630891 > [14:28] quite different error... [14:28] %C3%A4 is a 'ä' [14:28] adeuring: Yeah, that's kind of error I'd expect. [14:30] abentley: I assume that this error is raised for a failed int('630891ä') [14:30] (for the bug id) [14:30] adeuring: me too. [14:31] adeuring: a0 is non-breaking whitespace. [14:31] right [14:32] so it might be a replacement from the regular '\x20' space [14:33] adeuring: Maybe. Since googlebot is the source, I imagine it's in some web page, though. [14:34] abentley: right. And the s/\x20/\xa0/ might be deliberate: To avoid wrapping the URL... [14:35] though as far as I know most webbrosers ignore the "don't wrap" for \xa0 [14:35] adeuring: but of course URLs shouldn't have whitespace. [14:35] abentley: sure, but we can't stop the world mangling our URLs ;) [14:36] adeuring: we can, it's just hard to get venture capital :-) [14:36] abentley: it might help to add a check like "strip(path_element) == path_element" before the int(path_element) [14:37] ...where path element is the bug ID [14:37] adeuring: Yeah, that would work, or re.match('[0-9]*', path_element) [14:37] abentley: right [14:38] a nitpick: re.match('^[0-9]+$') [14:39] abentley: for even more fun: https://bugs.launchpad.net/mahara/+bug/630891%E4/+index [14:39] <_mup_> Bug #630891: Unable to delete Notification messages < https://launchpad.net/bugs/630891 > [14:39] adeuring: what the?? [14:40] abentley: %E4 is not vaild UTF8 [14:40] cool, right? [14:40] adeuring: That's wacky. === al-maisan is now known as almaisan-away [14:58] adeuring: merge proposals are also affected. [14:58] abentley: interesting. Again via an integer ID? [14:58] adeuring: Right. [15:00] adeuring: I'm gonna guess that everything that has an integer ID is affected. [15:00] abentley: seems this is worth a general helper function "check an int ID in a URL wfor all sorts of oddities" [15:03] adeuring: Yes, though I expect this kind of thing will rot. Maybe we should just reject URLs with whitespace from the beginning. [15:04] adeuring: Or more precisely, URLs with whitespace in the PATH. [15:05] abentley: the you can also add checks for the other issues: any byte value outside the ASCII set [15:05] more precisely: all bytes in the URL should have integer values between 33 and 126 [15:05] ...127 [15:06] ...after replacing the %xx encoding [15:07] ouch.. the latter check should _not_ be done for the part after '?' [15:12] adeuring: Right, only the PATH. [15:12] yep === matsubara is now known as matsubara-lunch [16:56] Project db-devel build #775: STILL FAILING in 5 hr 59 min: https://lpci.wedontsleep.org/job/db-devel/775/ [16:57] Project devel build #939: STILL FAILING in 5 hr 45 min: https://lpci.wedontsleep.org/job/devel/939/ === beuno is now known as beuno-lunch [17:52] sinzui: are you free to mumble? [17:53] jcsackett, I am otp. I will be available in 45 minutes [17:59] sinzui: dig. === beuno-lunch is now known as beuno [18:42] jcsackett, I can talk now [18:42] sinzui: cool. === matsubara-lunch is now known as matsubara [20:48] Anyone want a small (and possibly even slightly fun) JS review? https://code.launchpad.net/~benji/launchpad/bug-809511/+merge/70219 [20:53] sorry, gary claimed it so you all missed out [21:39] Hi, can anyone take care of reverting rev 13574 (from bug 810290). It's qa-bad, but I really have to go. [21:39] <_mup_> Bug #810290: no way to set scopes for incoming mail

< https://launchpad.net/bugs/810290 > [21:47] 13574 ? [21:49] allenap: does it work *without* the feature rule in place ? === matsubara is now known as matsubara-afk [22:35] Project db-devel build #776: STILL FAILING in 5 hr 39 min: https://lpci.wedontsleep.org/job/db-devel/776/ [22:46] Yippie, build fixed! [22:46] Project devel build #940: FIXED in 5 hr 48 min: https://lpci.wedontsleep.org/job/devel/940/ [23:02] StevenK, mumble? [23:09] sinzui: my sound is @!%@!%$!@^. rebooting [23:13] matsubara-afk: wow, nice defect finding === StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK | Critical bugs: 241 - 0:[#######=]:256 [23:42] hi all [23:54] Hi poolie. === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK | Critical bugs: 248 - 0:[#######=]:256 [23:54]