[00:30] fjlacoste: oh hai [00:30] fjlacoste: if you want to catch up in the evening or whatever, just let me know [00:30] lifeless: i think i'll pass today, sorry [00:30] fjlacoste: is cool [00:30] fjlacoste: hows the conf ? [00:32] lifeless: pretty good [01:03] wgrant: Can haz another look? [01:09] StevenK: Done [01:09] * StevenK looks for "This is terrible." [01:18] OMG, referencing a bug that *isn't* bug 933766. [01:18] <_mup_> Bug #933766: Update bug to use information_visibility_policy

< https://launchpad.net/bugs/933766 > [01:34] * wallyworld stabs thunderbird. using 3GB of memory and thrashing disk trying to get up to date with qastaging inbox. still waiting..... [01:35] wallyworld: Using Thunderbird to read the staging inbox? Ha. Hahaha. HAHAHAHAHAHA [01:36] yeah, i know now it is a bad idea :-( [01:36] lifeless: ping, if you have a sec can you peek at the MP for the email notice stuff. I've got two failing tests to fix, but shouldn't change much. https://code.launchpad.net/~rharding/launchpad/email_notice_959482 [01:36] wallyworld: Seriously, though, turn off the agressive caching, since Thunderbird loves to cache the entire message. [01:36] lifeless: the gpg and oauth adjustments are in a follow up branch I'm still working on getting [01:37] StevenK: is there a better alternative like pine or something worth considering? [01:37] Hahaha, pine. [01:37] offlineimap + mutt ftw! [01:37] Is your knowledge of MUAs like 10 years old? [01:37] never used those but perhaps i need to [01:37] I'm a big mutt user [01:37] mutt's generally fine for large mailboxes but do enable its header cache. [01:37] yea, definitely [01:38] http://blog.mitechie.com/2011/11/20/an-updated-email-config-2-offlineimap-mutt-and-dovecot-ftw/ [01:38] Exactly my combination [01:38] wallyworld: I think the staging inbox howto thingy shows how to configure offlineimap [01:39] * StevenK tends to be evil, and just uses wgrant to look at the staging inbox for him ... [01:39] StevenK: yes, i think it does. i never figured it would be mandatory to use it :-) [01:39] my license plate is 'cli4lif' :) [01:39] funny [01:39] wallyworld: It depends if you have 48GiB of RAM available and 3 days to wait? :-P [01:40] StevenK: i only have 4GB :-( [01:40] And a crappy i7 Atom that randomly reboots. [01:41] But that's what you get for buying a laptop based on the fact that it has a numeric keypad. :-P [01:41] it hasn't done that the past couple of days, touch wood [01:41] i bought it because it has a decent screen resolution [01:41] 1600x900 [01:46] wallyworld: My X201 is 1280x800, but I spend my time working on a 24" 1080p LCD. [01:47] StevenK: my main monitor is a 23" display but i also like to have a decent laptop screen too [01:47] Oh bugger, I put off voting in the DPL elections so long they elected zach without me. [02:17] StevenK: That's Disclosure Supreme, Flawless, and Marvellous Plan to you. [02:17] Haha [02:17] Tempted to raise that on the call tomorrow. :-) [02:23] * StevenK stabs Banshee four or five times. [02:24] I plug my mp3 player in, start Banshee, it spews 200 lines or so of Mono garbage tracebacks and then segfaults. [02:25] "feature" [02:25] And the Banshee devs complained when we switched the default away? [02:25] There is a reason I use Quod Libet as my music player. [02:26] exaile here. used to be a die hard amorak fanboi, but around a year or 3 ago they made me cry. so I gave up. [02:27] I gave up on amorak when it caused my (at the time) dual Athlon to melt into a puddle. [02:27] i think it was the crashing everytime I asked it to do something complex like "play this tune" that was the main kicker for me [02:27] Haha [02:28] much like how my previous smartphone would lock dead requiring a hard reset with complex tasks like receiving an SMS [02:29] * wgrant just uses Rhythmbox :) [02:30] Rhythmbox started acting very strange for me last release so I went back to the loving Python embrace of Quod Libet. [02:30] is that the current default? if Y, I'm sure I tried it, and gave up on it rather quickly [02:31] I used Banshee while it was the default, since Rhythmbox was indeed pretty broken. [02:31] I remember trying Exaile for a day (I think it was 0.22) and giving up in disgust, but I can't recall why. [02:31] StevenK: just think, your vote would not have changed anything [02:31] But switched back in early Precise. [02:31] lifeless: Meh, thank you for making me feel SO much better. [02:31] heh [02:31] StevenK: I failed to vote too [02:32] * StevenK goes to buy lunch and probably drown. [03:33] * wgrant stabs GIST in the face [03:33] wgrant: Oh? [03:34] Everything goes fine on dogfood until I try to FTI [03:34] I didn't drown, but it was a close run thing. Apparently, Sydney is going to get 140mm of rain over the next two days. [03:34] Heh [03:35] Ahaaa [03:35] Once the index is hot, fti is fast [03:43] StevenK: You probably have insane team memberships [03:43] StevenK: How do https://bugs.dogfood.launchpad.net/ubuntu/+bugs?field.searchtext=kernel and https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=kernel compare for you? [03:45] (Error ID: OOPS-71f5806d495ce2928a38ecae3e91b757) [03:45] and [03:45] At least 47 queries/external actions issued in 2.00 seconds [03:45] Erm [03:45] 2s? [03:45] Should be at least 6 [03:46] Oh, that's a prod oops [03:46] 2s on dogfood [03:46] Right, that makes more sense. [03:46] So, success? :) [03:47] (this early version of the feature flag has prejoining disabled, so there's a bit of death by a thousand queries still in play, so it will really be faster) [03:48] wgrant: nice [04:28] wgrant: I was lunching, do you still want me to check? [04:29] StevenK: More data is always nice. [04:30] Even though the data so far suggests that the Disclosure Supreme, Flawless, and Marvellous Plan lives up to its title. [04:30] wgrant: Hah, so. Timeout on prod, and 29second on DF [04:31] StevenK: What if you retry? [04:31] The fti and most of the table had probably dropped out of DF's cache [04:31] Given they're like 2GB all up, and DF has 4GB... [04:31] wgrant: 9.01 seconds on prod and 2.76 seconds on DF. [04:32] That's more like it. [04:32] I thought 9.01 should have timed out. [04:32] It must have ticked over 9 right after the timeout check. [04:32] StevenK: What are the timings for the two BugTaskFlat queries? [04:32] in the DF query log [04:32] Sigh, mawson is all the way over there. [04:32] No [04:32] * StevenK reaches for it. [04:32] Click link at top of page [04:33] "XX queries/external actions" [04:33] it's a link [04:33] expands query log [04:33] only if you're logged in and in the lp dev group there [04:33] 509ms and 1202ms. [04:33] Which StevenK is [04:33] Huh [04:33] Slow [04:33] k [04:33] lifeless: Pft, I'm a duck on DF. [04:34] Burn! [04:34] Burn which bit? [04:34] You [04:34] You're a witch :) [04:34] Really? [04:35] wgrant: Looks like my team memberships and such are a bit more insane than lifeless'? [04:36] Or lifeless may not have been logged in [04:36] Although [04:36] Yours should be faster... [04:36] I wasn't logged in [04:36] since you're a duck [04:36] It will ship all the perm checks [04:36] skip [04:36] Sigh [04:37] need more ram [04:37] My desktop has 4x more than mawson :( [04:37] hah, sso puts a spurious : after the fields in the what-fields-you-get confirmation form [04:37] Yeah [04:37] Has for ages [04:37] /ever [04:38] wgrant: But your desktop was manufactured sometime this century. :-) [04:38] wgrant: 143 queries/external actions issued in 11.12 seconds [04:38] AJAX Log ↓ [04:38] Yeah, DF doesn't do so well with a cold cache [04:38] 1895ms [04:38] SQL-main-slave: SELECT * FROM ((SELECT Person.account [04:38] I've just been browsing Launchpad's bugs, so Ubuntu will be long gone [04:38] Heh [04:38] So that's just listing your team administerships [04:38] 2248ms [04:38] I think mawson's disks have begun to fossilize [04:38] SQL-main-slave: SELECT BugTaskFlat.bugtask FROM [04:39] :( [04:39] 4991ms [04:39] SQL-main-slave: SELECT COUNT(*) FROM BugTaskFlat [04:39] 143 queries/external actions issued in 5.14 seconds [04:39] AJAX Log ↓ [04:39] I guess I should fix the last few tests failures and get this onto qas. [04:40] lots of SQL-main-slave: SELECT TeamParticipation.id, TeamParticipation.person, TeamParticipation.team FROM TeamParticipation WHERE TeamParticipation.person = 2980965 AND TeamParticipation.team = 430914 [04:40] 1606ms [04:40] SQL-main-slave: SELECT BugTaskFlat.bugtask [04:40] Yeah, those aren't even my fault :/ [04:40] 1764ms [04:40] SQL-main-slave: SELECT COUNT(*) FROM BugTaskFlat WHERE BugTaskFlat [04:40] 60ms [04:40] SQL-main-slave: WITH teams AS (SELECT team from TeamParticipation WHERE person=2)SELECT combinedbugsummary.distroseries [04:40] :) [04:40] lifeless: I think those TP checks might be subscriptions [04:41] Deciding whether you're subscribed or not [04:41] Pretty hilarious way to go about it, which is why it's completely plausible. [04:41] why would that page care ? [04:47] lifeless: It has the new bug subscriptions stuff on it. [04:47] Anything touched by that is cursed forever. [04:48] To be 500ms slower than it would otherwise be. [04:54] wallyworld: Can haz QA for r15100? [04:54] StevenK: still waiting for my qas inbox to finish syncing [04:54] * StevenK grumbles about having to feature flag the UI changes. [04:57] * wallyworld grumbles about yui tests in lxc core dumping :-( [05:00] wallyworld: You've enabled X forwarding in SSH? [06:20] Down to 92000 messages in the staging inbox... [06:20] Nearly there [06:39] wgrant: i don't use ssh with the lxc setup is use, i just sudo lxc-start -n lpdev and get a login prompt directly [06:42] wallyworld: Ah, that would do it. [06:42] wallyworld: No X server [06:43] wallyworld: Perhaps try xvfb-run [06:43] ah right. will do thanks. [06:43] wallyworld: Did you make any progress on QAing poolie's size limit? [06:43] wgrant: *still* waiting for fucking qas inbox to download everything [06:43] wallyworld: I just deleted 430000 mails from it [06:43] You might want to restart thunderbird [06:43] It's got like 4000 now. [06:44] already have. i can delete about 50000 at once. it's been swapping all day :-( [06:44] I did 100000 at a time. Just had to click Continue about 100 times. [06:44] Make sure you disable the message pane when doing bulk operations. [06:45] Otherwise it will try to render a list of threads. [06:45] that would help [06:45] i've lost count of the number of "script has stopped" dialogs i've clicked on [06:46] plus when the disk thrashes, the desktop stops accepting mouse clicks :-( not sure whether to blame unity or X or compiz [06:46] Sounds like you're swapping heavily :) [06:46] Need moar rams [06:47] yeah. normally get by fine with what i have [06:47] 4GiB? [06:47] yep === _mup__ is now known as _mup_ [07:18] wgrant: i see you sent a large email to qas. [07:18] my qas inbox finally cuaght up [07:18] It only took all day. [07:18] Is your laptop still thrashing? [07:18] yeah :-( [07:18] no [07:18] just finished [07:19] after 1000000 thunderbird restarts and clicking on Continue dialogs [07:20] Maybe you'll use offlineimap next time. :-P [07:21] I've just purged it [07:21] 42K messages, 0 need for them [07:21] StevenK: well, i didn't think i needed to :-) [07:21] you don't [07:21] if folk delete as they qa [07:21] too bad we don't clear qas inbox more often [07:21] lifeless: You tell funny jokes. [07:22] StevenK: apparently so [07:22] why don't we automatically purge once every couple of days? [07:22] lifeless: Did you just delete *everything*? [07:22] lifeless: Suprised you didn't make a ruling in terms of non-LP members doing QA. [07:22] I'd already deleted most of them. [07:22] noone has gotten theactivation energy up to do it [07:22] And I think you nuked my test mail :( [07:22] wgrant: i read it, looked ok [07:22] wgrant: there were 42K messages there, I wasn't selective [07:23] wallyworld: Ah, thanks. [07:23] wgrant: i marked the bug as qaok [07:23] lifeless: I usually leave everything from the last 24 hours [07:23] wallyworld: Even better. [07:27] wallyworld: I get "NotFound: Object: None, name: u'index.html'" [07:27] wallyworld: Nothing about a default view [07:28] wgrant: i was going by the string handed to the exception constructor in the base class. but anyway, it still refers to index.html which implies a page is expected [07:28] wallyworld: That's correct. [07:28] When browsing to an object in a browser, it will try to render the default view. [07:28] The default view is index.html unless overriden. [07:28] This is normal. [07:29] Eg https://launchpad.net/package-sets [07:29] Same for any object that doesn't have views [07:29] in this case i don't think it is because i see it as a case on an incomplete url [07:29] like lp/net/launchpa [07:29] typo [07:29] . not / [07:29] Structurally it is a complete URL. [07:30] Overriding as you've done is of minimal utility and breaks the convention around the rest of the codebase and every other ZTK app. [07:30] oh alright. not worth arguing about. i'll change it [07:31] To a user the difference is 0 [07:31] They don't see the traceback. [07:34] Hah [07:34] I'm going to accidentally fix the bug where milestones are duplicated on the advanced search page. [07:34] How convenient. [07:55] oh noes [07:55] we can't have less bugs [07:55] bugs are currency [07:55] You would say that. [07:56] YHBT HAND HTH [07:57] [07:58] bwaha [07:58] I need a dictionary for lifeless [07:58] it's funny because that's what StevenK trots out [08:02] czajkowski: urban dict probably has them all [08:02] czajkowski: or perhaps the new new hackers dict [08:03] lifeless: would you mind haveing a look at juju bug against lp please. https://bugs.launchpad.net/launchpad/+bug/983530 [08:03] <_mup_> Bug #983530: "charms" needs branch name consistency < https://launchpad.net/bugs/983530 > [08:03] lifeless: a swift google was helpful [08:03] SpamapS: hey ^ [08:03] my brain doesnt seem to want to fucntion at this hour of the morning [08:03] SpamapS: what is the problem ? [08:03] lifeless: See backscroll [08:03] good morning [08:04] From about 8 hours ago [08:24] lifeless: in charms, we often use 'bzr push lp:charms/foo' to create new charms. [08:25] lifeless: this creates lp:~yourname/charms/series/foo/trunk [08:25] lifeless: however, when branch-distro is run to copy forward and do the stacking jitterbug, it uses lp:~yourname/charms/series/foo/series [08:26] lifeless: the charm store code specifically targets 'trunk' because we need users to be able to have a way to say "this is my personal published version of foo" [08:26] wait, what ? [08:26] lifeless: so we can't really use branch metadata becaus we can't have two foo's for any one user [08:27] or rather we can't have two foo's for any one user+series [08:27] how does that impact the blessed charms ? [08:28] lifeless: the charmstore maps lp:~auser/charms/precise/foo/trunk to 'juju deploy cs:~auser/precise/foo' [08:28] lifeless: the blessed charms do have a 1:1 series<->charmname mapping, so I did suggest that we should just use that to workaround this. But it stands to reason that branch-distro should probably agree with push-to-create [08:29] SpamapS: are they able to say cs:~auser/precise/foo/trunk, if they want to ? [08:29] lifeless: no [08:29] lifeless: though I believe that is desired [08:29] its not part of the store *now* [08:30] so for users, this is irrelevant, because its only the blessed charms that are branched [08:30] right [08:30] the blessed charms should be listed as the development focus branch, in LP's package metadata [08:31] so they shouldn't be affected either [08:31] unless the charm store isn't using that pointer (which it should) [08:31] it is to map lp:charms/foo -> cs:foo [08:31] (which is the default, so 'juju deploy foo' [08:32] lifeless: the troubling part is the inconsistency [08:32] lifeless: I know we can mold the charm store loader to just load the dev focus branches as blessed regardless of their name. but they'll still have weird names [08:33] lifeless: also when copying forward, one thing that happened was any charms that were manually ported forward to precise were named 'trunk', and so were not detected as already existing. [08:35] wgrant: can haz +1 on that review? [08:45] wallyworld: Ah, sure. Was just waiting for the diff to update, then forgot. [08:58] wgrant: np. thanks. i am trying to make the next bb run :-) === almaisan-away is now known as al-maisan [09:37] cjwatson: It matters little, but spot the duplication in your most recent landing: [09:37] 120 + distro = bpph.distroseries.distribution [09:37] 121 + script = self.makeScript(bpph.distroseries.distribution) [09:45] StevenK: reasonable point; I was copying from test_getDirtySuites_returns_suite_with_pending_publication and test_getDirtySuites_ignores_suites_without_pending_publications and didn't notice [09:46] doesn't seem worth another landing to fix though, really? === al-maisan is now known as almaisan-away [11:00] SpamapS: ok, so I think that the bug may need some fine tunuing ;) [11:00] gnight [11:09] cjwatson: Nah. Like I said, it matters very little. If you care, you can do a drive-by in your next branch. Or you don't care, either is fine. [11:25] czajkowski: :-( [11:25] StevenK: now what have I done. [11:25] czajkowski: Your G+ reply, you bad person. [11:26] StevenK: hi we've clearly never met if you're only realising that now :) [11:26] I blame the blessed charms for todays corruption! [11:26] Hah [11:27] Which makes it SpamapS fault. [11:27] And the universe makes sense again. === almaisan-away is now known as al-maisan === matsubara-afk is now known as matsubara [13:08] hi all, could someone help me with an issue with translations? We've got the calligra source package in Ubuntu and its translations do not seem to get imported. Here are the details: [13:08] The imports queue is empty save for some manual uploads: [13:08] https://translations.launchpad.net/ubuntu/precise/+source/calligra/+imports [13:09] The po files were uploaded separately with the calligra-l10n package: [13:10] https://translations.launchpad.net/ubuntu/precise/+source/calligra-l10n/+imports [13:11] It's a KDE translation, which makes it a bit special and means the PO files will not be imported into any calligra-l10n template, but rather on the corresponding template in the calligra source packad [13:11] *package [13:12] So my question is whether someone could help me determine whether the PO files will end up in the right package or whether I should start to worry [13:13] I know there is a check somewhere in the LP code to determine if an upload corresponds to a KDE package and then takes care of all this, but I'm not familiar with the code other than knowing that this function exists [13:13] I just want to ensure the calligra translations end up in the right place and can be shipped in the language packs [13:32] abentley: standup? [13:55] dpm: hmmm, so there are imports on that l10n going back to Jan it looks like, 4k of them? [13:56] jtv: ping, I'm told you might be a translations master and know something about how this works? [13:58] rick_h, yeah (not sure about the translations part, though :). Back then the calligra package did not have any templates, so the translations were uploaded but had nowhere to go, as PO files only get imported if there is a corresponding template. Last week the templates were created and a new upload was made, which should in theory solve the issue. The way LP works, the 4k old translations will remain there, I believe, as there is no template associate [13:58] d with them. [13:59] dpm: ok, so there were some imports done after the 4/11 imports that didn't have a template? [14:02] rick_h, the templates were created last week (on the 10th or 12th, I think). All of the uploaded PO files before that date will remain in Needs Review (forever, I believe), whereas the PO files uploaded after should in theory get associated with a template and should be imported. And the "should get imported" part is what I'm trying to figure out :) [14:04] dpm: ok, I've ping'd jtv, I'm not sure atm how the imports work like this and asking in our stand up didn't get me much further. Let's see if he gets back to us and if not I'll try to find more help/guidance. [14:06] rick_h, ok, thanks for your help. jtv is on his day off, I think [14:12] jml, are you still hoping to merge your three testtools branches today? We're already making our own rollup branch, but we'd still love to have an official merge, let alone an official release. [14:13] We'll need to do similar dances for testrepository (we have one MP with no reply, with another on its way) and subunit (we need a release of the trunk in order to get some tag support changes that Robert added recently). [14:16] gary_poster: yes. about to do so now. [14:16] gary_poster: sorry about the muck-around [14:16] awesome thanks jml. [14:16] gary_poster: I'm going to apply lifeless's suggestion from the yellow testr review [14:16] gary_poster: and parametrize wrap_result [14:16] cool jml, thanks [14:16] benji ^^ [14:17] gary_poster: that will cause a conflict for you when you merge, but hopefully nothing too tough [14:17] fwiw, my excuse is that I moved house yesterday (taking the day off) and still don't have home internet today. [14:18] jml, ugh! moving house is never easy, and sometimes difficult for months or years later. :-) thank you very much for getting this through [14:25] having fast Internet changes *everything* [14:27] :-) [14:36] gary_poster, benji: tagger, tsfr-fixup and wrap-result-in-concurrent-suite all merged & pushed (lp:testtools r253). Let me know if there are problems. [14:36] thank you very much jml [15:02] rick_h: sorry, I'm not doing any more work tonight! [15:02] jamestunnicliffe, you'll need to ask one of the LP tech leads to approve a feature flag change to enable the view to members of Linaro [15:03] the feature flag will be something like "team:linaro registry.upcoming_work_view.enabled 1" (need to check the correct syntax/order) [15:04] jcsackett, how goes the bug subscriber branch? [15:06] sinzui, maybe you can approve that feature flag (^) change? [15:11] sinzui: i spent some time reading through the whole of the various subscription code last night, so i've been able to iron out those inconsistencies and am making progress. [15:12] there are some tests regarding the DB triggers i haven't gotten to looking at yet--there's a very good chance i'll be pinging you when i hit those. i expect they're going to be complicated. [15:12] salgado, sure, is the entry on the osa page? [15:12] sinzui, not yet. should I add it? [15:12] sinzui: would've pinged you earlier, but i was excited once i had things sorted out and just sort lost myself in fixing things. [15:13] jcsackett, okay, please ping me to talk if you are getting frustrated. I can listen and sympathise, and sometimes help fix [15:14] sinzui: will do, and thanks. :-) [15:14] salgado, add it the the ff section on https://wiki.canonical.com/InformationInfrastructure/OSA/LaunchpadProductionStatus [15:14] you can add me as the approver now since I agree that linaro needs to see the feature work [15:15] jamestunnicliffe, so, that (^) is what needs to be done, but the wiki page is internal-only so the next time you need to do it you'll just need to ask whoever approves the feature flag to add it to the wiki page as well [15:15] thanks sinzui! [15:16] thanks salgado! [15:17] (and sinzui) [15:23] sinzui: oh wise one, should a bugs description be editabled after a fix released so in theory it's closed be allowed to happen ? [15:23] bac: hi [15:24] bac: I've had a bit of a look at https://code.launchpad.net/~bac/testrepository/bug-949950/+merge/102317. Do you want to discuss it here, or would you rather a put some notes on the MP? [15:24] hi jml [15:24] jml: here is fine, as long as it is summarized on the MP [15:24] czajkowski, yes it should be editable so that confusing text is removed [15:24] bac: can do. [15:25] bac: I downloaded it and gave it a try. It looks like you'll only get test failures and start & end timestamps in the subunit stream. [15:26] jml: oh, really [15:26] bac: yeah [15:26] that isn't great [15:27] bac: I didn't think it was what you wanted. [15:27] jml: any thoughts on why that happens? [15:27] bac: it's not very obvious, but 'run' delegates to 'load' [15:28] bac: and 'load' uses the make_result() that your patch changes [15:28] to make something called 'output_result', which is the result responsible for UI output (which makes sense, I hope) [15:28] yes [15:29] immediately below that, is this: [15:29] filtered = TestResultFilter(output_result, filter_skip=False) [15:29] and it's that 'filtered' result that gets used from then on [15:29] so output_result never even gets the events for successful tests [15:29] (sorry for dragging this out, I'm figuring it out as I go along) [15:30] jml, np [15:31] I think the right thing to do is to push that TestResultFilter call down into the UI make_result [15:31] because, really, choosing which results to display is a UI decision. [15:32] jml: makes sense [15:32] bac: there'll probably be a bunch of annoying test fallout from that. [15:32] bac: sorry. [15:32] jml: and you're suggesting not applying the filter when we select --subunit? [15:32] bac: uhh, yes, I think so. [15:32] umm sort of [15:33] bac: there's a part of me that thinks there should be another option that controls whether only failures are shown vs full results [15:33] bac: and that the default should stay as is regardless of whether the output is the pretty text output or a subunit stream. [15:34] sinzui: even after the bug has been fixed released? surely editing the description then is confusing [15:35] jml: so grow a '--full-results' (modulo spelling). would that be only for the run command? [15:35] sinzui: an example is https://bugs.launchpad.net/launchpad/+bug/272826 which was edited today [15:35] <_mup_> Bug #272826: "Ubuntero" inappropriate for female contributors < https://launchpad.net/bugs/272826 > === al-maisan is now known as almaisan-away [15:35] bac: run & load yes. [15:36] jml: ok. so if you'll disapprove that MP i'll look at doing that this afternoon [15:36]