[00:33] wallyworld_, StevenK: You've a revision each to QA. [00:33] Then we can unbreak JS :) [00:37] wgrant: I'm distracted by Apache and convoy, but also still trying out how to QA it [00:37] SetEnv doesn't hit os.environ :-( [00:38] wgrant: do you know of any private branches on qas? [00:39] Make one [00:39] wallyworld_: All of lp-production-configs [00:39] right, thanks [00:45] wgrant: qa is done [00:49] * StevenK kicks Apache, and looks at his QA. [01:06] wallyworld_: Thank [01:06] s [01:06] np [01:07] Mine is done too [01:07] wallyworld_: Jon marked my combo-url branch as Needs Information :-( [01:07] Great. Now we just need the DB user setup. [01:08] * wallyworld_ takes a look [01:13] StevenK: i think a fair point is raised? rf already does sudo stuff to install apache, so it could do the new stuff as well [01:14] wallyworld_: You can NOT re-run rf-setup after it has run once [01:14] We need to handle existing setups as well as new ones [01:14] sure, but for new installs [01:14] StevenK: right, but for those starting from now on it could/should be there right? [01:14] +1 onwhat rick said [01:14] StevenK: so it seemed like a small missing automated update for the branch to be "complete" [01:14] New installs will just work with rf-setup [01:15] I was hoping he'd ok it with the request for that added, but didn't [01:15] Current installs need to install mod-wsgi, and run 'sudo make copy-apache-config' if they want to play with the loader [01:15] yes, and he was suggesting that be done in rf wasn't he? [01:15] In rf-setup? [01:16] yes [01:16] Like I said, we can't? [01:16] It is already handled in rf-setup [01:16] ok, so was the needs info request redundant? [01:16] if it's already all done [01:16] I have no idea, and you've confused me. [01:16] rf-setup already install mod_wsgi and creates the symlink directory for the convoy root? [01:17] rf-setup install mod_wsgi, and if I'm reading the makefile correctly, it will create /srv/launchpad.dev too [01:17] i think the above is what jon was askin for, if not done already [01:18] StevenK: so the answer is that it already does that. I don't think we saw it that way reading the diff [01:18] rick_h: Right -- it requires some knowledge of what rf-setup does [01:18] so, bottom line is that rf-setup needs to prepare a clean system to be able to run the combo loader. if it can do that, the needs info is redundant [01:18] wallyworld_: +1 [01:20] and we also need to the tools/make target(s)/process doc to be able to add the required symlink/whatever to an existing system [01:20] wallyworld_: I was going to announce that on launchpad-dev once combo-url lands [01:21] yeah, as i thought you would, just rounding out the requirements so we all understand [01:21] or agree [01:24] Sigh. WSGI sucks. [01:24] "Environment variables are too hard, so you need to deal with it in this dict [01:42] So to get convoy working with overriddable roots, I had to copy the inner function in combo_app :-( [01:43] Just returning the app didn't work, since I can't pass the environ and start_response into the inner function in combo_app. [01:43] And this, kids, is why nested functions are bad. [01:44] StevenK: huh? [01:44] StevenK: if you wsgi layer another app on top of the convoy wsgi app and chage convoy to pull from there no worky? [01:44] or we don't want to change convoy for that, it would suck [01:44] rick_h: WSGI layer? [01:45] sec, let me pull it up [01:45] rick_h: Using def application(...): return combo_app(root) no worky [01:46] StevenK: right right [01:48] StevenK: hmm, so I think what we'd have to do is move the app aprt out of inside of combo_app() in convoy' [01:48] and then we'd wrap that ourselves with our own wrapper [01:49] the problem is that convoy doesn't expose the raw wsgi app without the root already set [01:49] Right [01:49] that's ok thoguh, should be a small patch to convoy to get it so we can import app vs combo_app [01:49] and then we'd have raw access to setting root as we see fit ok [01:50] So we *could* change convoy to in the inside app call to set root from the environ if it's None [01:54] rick_h: But changing it so the inner function becomes an exportable one sounds fine too [01:55] StevenK: right, but I'd rather do something like tihs: https://pastebin.canonical.com/59462/ [01:55] which is a completely off the cuff 2min take at it [01:55] then we'd basically change our .wsgi files to do our own combo_app with our own values and can change them as we see fit [01:56] Right [01:56] Why partial() ? [01:56] just because it keeps their signature all the same [01:56] I'm sure combo_app could be turned into some sort of decorator but that would require me to hit more docs [01:56] return partial(.. ? :-) [01:57] I jsut mean that I had to add extra kwargs to app() so that their combo_app thing works the same [01:57] and those values need to get passed through, since we're returning a function, not a result you'd either have to decorate it or partial it or something [01:58] but if I'm off let me know, I'm 3 glasses of wine into the night before bed so grain of salt and all that jazz [01:58] I was hoping I could just use os.environ, but I'm not that lucky [01:58] StevenK: well our wrapper could once the app is exposed on its own [01:59] but right, we're going to need to do another patch to convoy to get it there [01:59] We'll need to patch it before it hits qas [01:59] ok, well I can do that tomorrow morning if you want. [01:59] Because as it stands, the version in our PPA will only look in /var/tmp/convoy [02:00] I'm working on updating the tets and such, but that requires your convoy patch to land first so I'm stacking branches like there's no tomorrow [02:00] StevenK: right [02:00] Haha [02:00] rick_h: I'm happy to work off your pastebin [02:00] StevenK: k, if it falls apart shoot me an email and I'll pick it up come morning [02:00] rick_h: Okay, thanks! [02:59] stub: In PL/pgSQL I can INSERT from a ROWTYPE variable, but I don't seem to be able to UPDATE all fields without naming them explicitly. [02:59] Is there any benefit to an UPDATE over a DELETE and INSERT? [02:59] wgrant: syntax sucks there [02:59] * stub ponders [02:59] I guess in 9.2 there might be (what with immutable columns and all that), but I suspect now there's no difference. [03:05] wgrant: Two statements get run - two lookups etc. The end result on disk will be the same. [03:05] Unless the only change is to unindexed columns [03:06] Hm? [03:06] Won't the UPDATE create a new tuple regardless? [03:06] and therefore poke the indexes the same way [03:06] ? [03:07] So if you update a row, and don't touch indexed columns, and the new row can be written to the same page, the indexes don't need to be rewritten. [03:07] Ah [03:07] Anyway, I guess I'll just name the columns explicitly :/ [03:08] Yer. You can use dynamic SQL, but that solution sucks worse than the problem [03:08] Yep [03:08] Or plpython, but that will be slower due to the type casting that needs to go on [03:11] plpython is never the solution :) [03:13] Lots of improvements have gone into plpython in 9.1 [03:14] Yes, but it's still terrible. [03:19] stub: I thought you could write to indexed columns and only the affect indices must change (and they may end up with same-page updates too, under appropriate circumstances) [03:23] "UPDATEs and DELETEs leave dead tuples behind, as do failed INSERTs. Previously only VACUUM could reclaim space taken by dead tuples. With HOT dead tuple space can be automatically reclaimed at the time of INSERT or UPDATE if no changes are made to indexed columns. This allows for more consistent performance. Also, HOT avoids adding duplicate index entries." [03:23] ^^^ was what I was thinking off, pulled from the 8.3 changelog [03:24] hmm, I should dig up the code and check the conditions. It makes sense to me that the same core logic would allow a wider ranger of conditions. [03:24] I'm not sure about the optimization you mention [03:25] anyhoo, I'm not really here today ;) [03:56] StevenK: ping [03:57] rick_h: Hai [03:57] rick_h: Aren't you supposed to be sleeping [03:57] StevenK: so stupid ?, why do we need the ENV based root for convoy? [03:57] StevenK: yea, but I can't stop thinking about this, I don't thinkt he answer I gave you will help [03:57] Haha [03:57] and then I got wondering why we're doing this anyway [03:58] rick_h: I just put up an MP: https://code.launchpad.net/~stevenk/convoy/exportable-app/+merge/91601 . That should answer your question [03:58] because if we update convoy we can set the root to /srv/.../ right? [03:59] StevenK: right, but when are we going to have to change the root in the wsgi config in apache? [03:59] that's the part I'm missing [03:59] rick_h: So, asuka runs both staging and qastaging [03:59] rick_h: So it will have convoy installed, and the WSGI file in /usr/share/convoy/convoy.wsgi [04:00] and they're not the same rev/updated together? [04:00] rick_h: staging uses db-stable and qas uses stable [04:00] e.g. is there a reason they can't share the same combo loader? [04:00] And no, they aren't updated together [04:00] StevenK: ah right, ok...well @#$#@$ [04:00] they can share the same combo loader as long as: [04:00] nvm then, carry on. Thanks for updating me [04:00] rick_h: So we need a way to inject a different root directory [04:00] - we never ever do an incompatible change to it [04:01] - we do something to accomodate the different revno sequence between db-stable and stable [04:01] the former point is probably pretty easy, as incompatible changes will screw deploys anyhow [04:01] StevenK: ok, so this change will do what you need? You've tested this? [04:01] the latter point is harder [04:01] rick_h: I've tested both cases of combo_app() and _application() [04:01] StevenK: because we're still just building a callable we return and don't actively change the root here are we? [04:02] StevenK: right, but I mean when you use _application in LPs .wsgi file it will listen to the ENV path as you wnt? [04:02] def application(environ, start_response): [04:02] root = environ.get('CONVOY_ROOT', '/var/tmp/convoy') [04:02] return _application(environ, start_response, root=root) [04:02] Our WSGI file with that change [04:02] StevenK: right, but that's called once when apache starts up the wsgi app [04:03] StevenK: so whatever one is the latest one wins? How is this passing two different roots? [04:03] StevenK: because we're saying one apache .wsgi file is serving both servers right? [04:03] rick_h: The environment variable in environ will be different for both staging and qas [04:03] * rick_h should go to bed, probably missing something easy [04:03] StevenK: ok, so in apache are there one or two convoy servers running? [04:04] There will be two [04:04] StevenK: so why couldn't we pass the root kwarg to the old combp_app thing? [04:05] StevenK: ah I get it, the environ is where you're getting it from [04:05] Right [04:05] StevenK: so you need the app to be up first, ok, sinking in now. [04:05] And Apache's SetEnv does not hit os.environ [04:05] I was thinking a system ENV variable like os.environ [04:05] StevenK: right right, remember hitting that before now that you mention it [04:05] rick_h: Clear as mud? [04:06] ok, the world makes sense again, I can go back to sleep. Thanks for walking me through it [04:06] rick_h: I should probably thank you for the patch in the MP. [04:06] My guilt may not let me claim credit. :-P [04:06] StevenK: heh, it's ok. Consider it a freebie :P [04:07] rick_h: I've been in free software since 2000 -- I can't not mention you. :-P [04:07] It's just not done. [04:07] anyway, see you all again in 6hrs ish [04:16] lifeless: Can I nail bug 805546 shut? [04:16] <_mup_> Bug #805546: persontransferjob does not have a unique oops prefix < https://launchpad.net/bugs/805546 > [04:16] wallyworld_, StevenK: The AJAX log is still broken on production, despite the LPJS thing being deployed. [04:17] :-( [04:34] is that all that look broken? [04:36] No idea. [04:42] And all my qa done for me, ta muchly :) [04:47] Haha [04:58] wgrant: Wish I knew how to debug it [04:59] wallyworld_: Can haz update of the kanban board? [05:00] Since wgrant has gone and done the one bit I was about to [05:00] done. didn't realise you were so anal about it :-P [05:16] lol [05:17] * StevenK sighs at bugs including OOPSes that have been pruned [05:18] StevenK: does it generate good oops ids now? [05:19] lifeless: PTJ? I have no idea. I thought we didn't use prefixes for oopsii at all now? [05:19] We really must get LaunchpadScript to inject a sensible reporter. [05:29] StevenK: if there is no oops prefix configured for it in the configs, then it should get a sensible one at runtime [05:29] as long as a) the base config its using is sane (e.g. has 'production') and b) it attempts an override, which I think the job runners all do [05:30] lifeless: The bug was reported when it would oops with REPORTIFSEEN [05:39] Can haz review? https://code.launchpad.net/~stevenk/launchpad/invalid-mp-api/+merge/91607 [05:46] stub: ^ You're on the hook as OCR. [05:47] That will teach me for starting on time. [05:47] It's a very short MP [05:47] I'll just finish typing up this db review [05:53] StevenK: r=stub [05:57] stub: Thanks! [06:12] wgrant: The CommercialSubscription query is ~12ms on DF, and ~4ms when I create the index on CS.date_expires [06:16] StevenK: It's a small table atm, but still worth the index [06:16] can has explain with and without? [06:19] wgrant: http://pastebin.ubuntu.com/831004/ -- but it doesn't seem to use the index? [06:22] Ah, so the 12ms was cold? [06:22] And the 4ms reasonably hot? [06:23] Perhaps [06:24] Anyway, looks like there's so few rows that it doesn't even try the index, so let's not bother. [06:25] We'll have other problems once the table starts getting big. [06:25] Oh, right, Postgress will just decide to not touch the index? [06:26] Right. The whole table probably fits on just a page or two. [06:26] Using the index would double the reads. [06:26] relpages [06:26] ---------- [06:26] 7 [06:26] But similar argument. [06:27] The index is 4 pages, so yeah, I think the planner's decision is reasonably correct. [06:33] stub: I wonder if a sequence column is missing from specificationworkitem [06:33] They presently seem to like to keep them roughly in implementation order. [06:33] But perhaps not. [07:13] Hm [07:13] Why is everything segfaulting... [07:14] Everything? [07:19] wgrant: I've added a comment re: sequence column. [07:27] StevenK: Well, tail still worked, but pretty much everything else I could find segfaulted in libc6 startup [07:27] I think x-x-v-ati was doing bad thing. [07:28] Yet again another reason that fglrx is a pox. [07:33] pox? [07:33] POS? [07:34] StevenK: Hmm? x-x-v-ati isn't fglrx [07:36] nigelb: http://en.wiktionary.org/wiki/pox [07:45] oh.lol. === almaisan-away is now known as al-maisan === jtv is now known as jtv-C8H10N4O2 === jtv-C8H10N4O2 is now known as jtv === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [09:05] good morning === al-maisan is now known as almaisan-away [11:37] morning [11:38] hey rick_h [11:40] rick_h: I find you online at the start of my day and end of my day. Do you sleep at all? :) [11:40] nigelb: of course, during your day :) [11:40] heh [12:15] StevenK: still around? Is your combo-url branch updated and ready for review again? === almaisan-away is now known as al-maisan [12:54] rick_h: It is, yes. You can also prod sidnei to review my convoy branch. [12:54] StevenK: will do, ok I'll mark that branch as needs review. Thanks [13:41] 35 [13:46] anyone know a trick to download all translation .pot files for a project/lang at once? https://pastebin.canonical.com/59476/ is the question [13:46] lp-translations-tools just seems to do multi uploads [13:46] and all the wiki info is about downloading one .pot at a time === matsubara is now known as matsubara-lunch [14:01] adeuring: deryck gone through RT, new projects, POT translations, and some spam monitoring [14:05] rick_h, ack, cool. [14:40] deryck: this is the first one, I wanted to go over the new templates for testing and make sure that they looked good to you: https://code.launchpad.net/~rharding/launchpad/combo_yui_tests/+merge/91478 [14:40] so that's the updated templates and a couple of modules changed over to it [14:40] deryck: and this is the next big changeset https://code.launchpad.net/~rharding/launchpad/combo_yui_tests2 [14:40] with #3 in the works as well [14:40] rick_h, ack, will look now [14:40] np, heading afk [14:53] sinzui: saw your notes on my MP; i've pushed up changes addressing them. [14:54] I have approved [14:55] jcsackett, about the date in the XXX: https://dev.launchpad.net/PolicyandProcess/XXXPolicy === al-maisan is now known as almaisan-away [14:55] sinzui: yeah, i went looking for that after your comment. [14:55] I think the policy was added after we could not tell what sabdfl, kiko, and stevea meant in their comments [14:58] sinzui: make sense. i've updated the wiki page too, as the date example for the python was another ambiguous case, and only became clear when you read the TAL example. [14:58] thanks [14:58] basically, when dealing with multiple country date formats, numeric dates are problematic. :-P [15:08] sinzui: do you have time to talk about bug 741234? i'm contemplating tackling that next. [15:08] <_mup_> Bug #741234: product:+code-index merge proposal queries do not show private bugs visible by assignment < https://launchpad.net/bugs/741234 > [15:09] jcsackett, I do === matsubara-lunch is now known as matsubara [15:19] jcsackett, confirm you do not see this: https://bugs.qastaging.launchpad.net/gdp/+bug/864587 [15:19] <_mup_> Bug #864587: compiz crashed with SIGSEGV in PrivateWindow::configureFrame()

< https://launchpad.net/bugs/864587 > [15:20] and look at this : https://code.qastaging.launchpad.net/gdp [15:28] nigelb: so when did you want this presentation on lp thingy? [15:29] lifeless: heh, it was last week. [15:30] I completely forgot. [15:30] ah well :) [15:30] ^-^ [15:40] deryck: my QA's giving some really weird results. Can we chat? [15:43] abentley, sure. let me just get coffee. was just about to do that. and then we can chat. [15:43] deryck: cool [15:51] abentley: deryck adeuring heads up, back and numb wheee [15:51] rick_h: hehe. [15:51] rick_h, oba-kba [15:52] abentley, ready now…. mumble or hangout? [15:52] deryck: mumble. [15:53] jcsackett: heads up, StevenK updating the MP for the convoy stuff: https://code.launchpad.net/~stevenk/launchpad/combo-url/+merge/91203 [16:01] danhg, I am going to attempt a last minute change the interactive mockup. Many of the tests I am writing for you require a new project. I think we want a start page where you choose a young or old project so that the data looks right for the task we are testing [16:02] hey sinzui [16:02] OK sure [16:03] danhg, I think i want to change the names of the people and teams too because the nonsense is a barrier to knowing you have done the right thing. eg football teams and politicians do not on you mind when you are looking for project-related groups [16:04] If it it is difficult to implement these changes, we could start some of the tests off with an ''imagine that this is a new project'' narrative to put testers into the right frame of mind. [16:04] If it can be done though, that's great [16:05] Sure, the comedy names make it seem 'less real' [16:08] danhg, okay. I will set a limit of 2 hours to do this. [16:10] OK. Thanks sinzui. I'll be working most of this evening so we'll be able to talk things over later than normal. [16:36] rick_h: i've replied, thanks for the heads up. [16:36] jcsackett: thanks === beuno is now known as beuno-lunch === beuno-lunch is now known as beuno [17:13] sinzui (or anyone): we're supposed to be removing remove_security_proxy_and_shout_at_engineer, right? i have stumbled across a use of it and am wondering if i should replace it. [17:19] jcsackett, we can remove them. It is okay to remove the proxy to work with the object, but that naked object should not be return to an ignorant callsite [17:20] * jcsackett nods. [17:20] ok, that's what i thought. [17:20] so when it's just a onetime use to manipulate something in a test, we're good. [17:20] absolutely [17:20] fantastic. [17:27] flacoste: taking cynthia for a bit; not sure when I'll be back to keyboard, I should be on skype though if you want to ping me for our call [17:49] sinzui: this test look like it's setting up the scenario we discussed? b/c it's passing, and given our test and our assumptions it shouldn't. http://pastebin.ubuntu.com/831640/ [17:50] i've poked at it a bit, and i think either i'm missing something or an assumption is wrong. === mpt_ is now known as mpt [17:53] jcsackett, please wait while I stop the bank from contriving a scheme to make me default on my mortgage [17:55] sinzui: sure, that sounds like a priority. === mpt_ is now known as mpt [18:41] jcsackett, I ca talk now === matsubara is now known as matsubara-afk [18:46] deryck: changing the feature flags didn't solve it. Copying the remote feature flags to my dev instance didn't solve it. [18:46] I mean Copying the remote feature flags to my dev instance didn't reproduce it. [18:48] sinzui: excellent. i was briefly away, but i'm back now. [19:00] abentley, hmmm, ok, very weird. [19:00] abentley, I've got a call now and I can look deeper after that. [19:08] sinzui: http://pastebin.ubuntu.com/831740/ [19:16] jcsackett, http://pastebin.ubuntu.com/831747/ [19:17] deryck: I think it's from dupe detection. [19:19] jcsackett, do you see the linked bu on https://code.qastaging.launchpad.net/~sinzui/gdp/trunk-1/+merge/77651 [19:29] jcsackett, https://code.qastaging.launchpad.net/gdp/+activereviews [19:30] jcsackett, https://code.qastaging.launchpad.net/gdp/ [19:34] jcsackett, https://bugs.launchpad.net/launchpad/+bug/723783 [19:34] <_mup_> Bug #723783: distribution and project group index pages have wrong header < https://launchpad.net/bugs/723783 > [19:43] abentley, ok, interesting. [19:43] abentley, duplicate comment detection? [19:51] deryck: Yes, I think I saw something about that in the bug message handling. [19:52] abentley, that kind of makes sense. So nothing wrong with your work per se, just the kinds of comments you posted as tests being mistaken as dupe comments? [19:53] deryck: That's right. Not detected locally, because a unique subject, author, bugtask & bug is used by default. [19:53] abentley, right, makes sense [19:53] abentley, glad you tracked it down. [20:09] * deryck goes offline for school pick up, back soon [20:47] deryck, rick_h: did interrupt duties: bugs, RT, questions. === matsubara-afk is now known as matsubara [21:54] wgrant: hey [21:54] wgrant: whats the status of the heat plumbing [21:59] lifeless: I was planning on waiting for a few days of insufficient complaints before ripping it out. [22:00] wgrant: doit [22:00] or at least, lets get the branch ready to troll [22:02] lifeless: Disable the max heat update code, and the aging job? [22:02] s/Disable/Delete/ [22:02] yeah, and remove the flag [22:07] lifeless: Do you know what's happening with removing the old bug listing code? [22:07] deryck: ^ [22:07] deryck: also I imagine its too late today; shall we talk tomorrow? [22:09] lifeless, yeah, let's chat tomorrow. [22:10] and we haven't made plans for removing the old code yet. [22:10] how about "while we're on maintenance" [22:11] There's a regression which means we're still using the old code on one of the feeds. [22:11] ah right. [22:11] meant to add that to our board actually [22:12] our board is kind of full right now though [22:12] Heh [22:24] lifeless: Like blueprints? :) [22:24] Although Linaro seems to be trying to prevent it :( [22:28] rick_h: Still here? [22:32] wgrant: blueprints is very heavily used; there hasn't been a real proposition to *remove* it, ever - but there is one to fold it into the rest of the system better (issuetracker) [22:34] lifeless: Please file bugs about use of sourcecode [22:35] StevenK: please reply to the thread and say 'yay'. [22:40] Bah, then I need to find the mail again [22:40] I will when I dig my way out of my warthogs folder [22:59] lifeless, re policy [22:59] i do wonder if there ought to be some at least rough calculation of bugs from a particular type of change [23:00] i guess people do this alreday with "X is dangerous" or "Y could close many bugs" [23:02] poolie: that might be nice too; as jml says though, these things require knowing the future (or at least trying to predict) - so they are intrinsically harder than knowing the now. [23:04] well, that's what i'm trying to get away from [23:04] i'm talking about looking only at currently open bugs [23:05] for example, [23:05] we know removal of a moderately-used feature tends to cause about A amount of noise/complaint [23:05] we also know having semi-working hg imports causes B amount of noise [23:05] i can't work out how to make this very concrete though [23:06] interesting to think about though [23:06] no reason we can't evolve the policy as better rules are created / become feasible [23:08] A general question for anyone; I have a merge proposal that is approved. Should I do something more to land the change or will that happen automatically? [23:10] you need an LP core dev to land it for you [23:10] the person that approved often will, but its best to nag (gently) here :) [23:10] mabac: I'm happy to land for it you, please link me the MP. [23:13] StevenK, thanks. it's https://code.launchpad.net/~mabac/launchpad/login-raises-non-string/+merge/91265 [23:13] lifeless, thanks, that's kind of what I was going for :) [23:14] mabac: Please set a commit message on the MP. [23:14] I'll toss it at ec2, just to be safe. [23:16] is https://lp-oops.canonical.com/?oopsid=OOPS-4cc7d8d466ed2a4569ebb00fa667f23e just me because of the number of branches my teams own? [23:16] hi mabac! [23:16] mabac: Too slow. :-) [23:16] StevenK, sorry about that. it's added [23:16] StevenK, hmmpf ;) [23:16] james_w, hi! [23:16] mabac, how is connect so far? [23:17] james_w, it's great. we miss you of course :) [23:17] james_w: I don't know :P [23:17] james_w: but I'll have a look. You should be able to see it too... [23:18] I did look, and that's my guess [23:18] james_w: do you still own all of ubuntu? [23:18] yeah [23:18] indirectly [23:18] ~ubuntu-branches, which I am a member of [23:18] thats probably it [23:18] I can't see any code indexes, which is mighty annoying [23:18] mabac: That branch is hitting an ec2 instance to run tests first. I'm not expecting any failures, but you should get a mail in about four hours from it. [23:19] I was wondering if it was just me, as that would explain why it wasn't fixed yet [23:20] StevenK, cool, thanks. it's not the most intrusive change I can imagine. good for me to learn the process before I get to propose any more significant changes. [23:20] mabac, say hi to everyone [23:23] james_w: there is or was a bug about it [23:23] james_w: its nasty business to fix [23:23] james_w, the Infra team waves back from our hacking room!