* StevenK takes ILaunchBag out the back, shoots it in the head, and then stabs it for good measure.00:19
* mwhudson cheers StevenK on00:34
mwhudsonStevenK: for real?  or is that just wishful thinking?00:34
StevenKmwhudson: Wishful thinking00:35
wgrantbranch is down more than 90%, but it's still there :/01:16
lifelesswgrant: 100000 loops, best of 3: 7.32 usec per loop03:29
lifelessbah, typo03:31
lifelessah, thats better03:40
lifeless:!bash ./profile03:40
lifeless10 loops, best of 3: 21.7 msec per loop03:40
wgrantlifeless: Heh, that's slightly less implausible.03:41
wgrantIs that compile?03:42
lifeless10 loops, best of 3: 21.9 msec per loop03:44
lifeless10 loops, best of 3: 30.8 msec per loop03:44
lifelesscomfortably faster b/4 optimisation03:55
lifelesscould do 1500 items of that scale without worry within a second, I suspect03:56
lifelesswill want some detailed tuning03:56
wgrantThe previous timings were compile, I assume?03:59
lifelessrunning the same template04:00
lifelessbut with no data04:00
lifelessbecause lp.cache != what we feed the template04:00
lifelessso all the top level lookups found nothing04:00
wgrant1500 * 30.8 > 100004:01
lifelessthats pystache04:01
wgrant1500 * 21.9 > 100004:01
lifelessyou are forgetting the /7504:01
wgrantOh, so that's the template for the whole list?04:01
wgrant(also, lpnet average down to 395% from the 560% it was 2 weeks ago)04:02
StevenKwgrant: Do you want to review https://code.launchpad.net/~stevenk/launchpad/no-active-for-dsd-spr/+merge/93762 ?04:31
wgrantStevenK: r=me04:33
wgrantSo, that's OOPS #3 (not #2 as I thought earlier) fixed.04:33
wgrantIf you fix #1 (easy) and #2 (probably trivial) as well, we'll be at around 100 exceptions per day.04:34
wgrantAnd #4 isn't real04:34
wgrantStevenK: Actually04:35
StevenKwgrant: Hmm?04:35
wgrantMm, I guess it's fine.04:35
wgrantSince it picks the most recent.04:35
wgrantAnd filters by version04:35
wgrantSo there shouldn't be an issue with too many or non-latest resolds.04:36
* StevenK looks for our #1 OOPS04:36
wgrantIt's None: None04:36
wgrantWhich is usually log.warning or log.error04:36
wgrantIn most cases it's garbo whinging that a task timed out.04:36
wgrantCan probably be demoted.04:36
StevenKAh, bug 88804904:37
_mup_Bug #888049: garbo-frequently logged an oops <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/888049 >04:37
wgrantgnargh I hate security proxies breaking object identity.04:38
stubGarbo tasks timing out are a concern - we need to ensure it keeps up, even if that means increasing time slices or moving hourly jobs to daily or on both lists04:38
wgrantstub: Mm04:38
wgrantWe care that it keeps up in the end.04:38
wgrantAt present to care that it keeps up daily we have to put it in garbo-daily.04:39
wgrantWhen in fact we may want to do it -hourly, but don't care if it lags for two hours.04:39
StevenKOr more, thanks to the backups04:39
stubYes, and the only way we have of doing that without adding features is by ensuring it always finishes in its allotted time slice (which might be changed)04:39
stubBackups were an issue, and we fixed that.04:40
stubThey where a problem04:40
wgrantThey still are AFAIK04:40
stubBackups are happening on a slave and garbo isn't looking at that slave afaik. If it is, that is a problem we need to fix.04:40
wgrantI thought that didn't matter.04:41
StevenKThe OOPSes don't look like a problem of not running04:41
StevenKThey are hitting the slice limit and being killed04:41
StevenK<oops-message-0>: [BugHeatUpdater] Task aborted after 3299 seconds.04:41
wgrantkeeps getting blocked by librariangc and autovacuum now :/04:42
wgrantInstead of backups.04:42
wgrantBut yes, bugheatupdater is terrible.04:42
wgrantI'm not sure why.04:42
stublibrariangc? That is a new one. How is that blocking? Long running transactions?04:43
wgrantBut the whole lot often get blocked by autovacuum for an hour04:43
wgrantLong running transactions on both counts, yeah04:43
wgrant2012-02-20 02:53:23 INFO    [DuplicateSessionPruner] Blocked on 1:42:21.965885 old xact postgres@launchpad_prod_3/25895 - <HIDDEN>.04:43
wgrant2012-02-20 02:53:23 INFO    [DuplicateSessionPruner] Blocked on 0:44:56.982871 old xact postgres@launchpad_prod_3/11353 - autovacuum: VACUUM pg_catalog.pg_index.04:43
stuboh... librariangc is a victim, not a cause04:43
wgrant2012-02-20 00:02:06 INFO    [BugHeatUpdater] Blocked on 1:07:30.239287 old xact librariangc@launchpad_prod_3/32758 - <IDLE>.04:43
wgrantPossibly true, indeed.04:43
StevenKRight, so it's using self.log.warn()04:44
stubSo we can silence these (don't report a task timeout if we got blocked for reasons beyond our control)04:44
stubOr we can make dblooptuner ignore autovacuum, which scares me a little.04:45
wgrantPerhaps we record the total time each task has been blocked.04:45
StevenKstub: My plan was to fix looptuner to not warn, so it stops causing >100 OOPSes a day04:45
wgrantAnd if it's more than $threshold, don't warn.04:45
stubThat is easy enough to do IIRC04:46
stubWe can go with that.04:46
stubMonitoring long running transactions can be done better than watching batch jobs produce errors04:46
nigelbhaha, I just read flacoste's email babout serial tab openers team. lol.04:49
StevenKnigelb: Did you see the cricket? :-P04:50
wgrantstub: That BranchLookup.getByUniqueName fix freed 1.5 cores on wildcherry.04:50
wgrantWhich might almost mean that we're not screwed if we have to failover.04:51
nigelbStevenK: Nope, been offline helping run an  conference.04:51
StevenKnigelb: Aus 5/288, India 17804:51
StevenKThat was last night04:51
nigelbAh. I was a zombie last night after being on the road all day.04:52
nigelbJust woke up after a 12-hour glorious sleep.04:52
StevenKHmm, switching to self.log.info() means it doesn't get printed by the doctest now. :-(04:52
* StevenK can't even work out how the warnings are injected into the stream04:54
stubwgrant: \o/04:56
nigelbStevenK: http://www.devsigh.com/sigh/6705:09
* StevenK sighs at looptuner.txt05:16
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
wgranthow does AMD manage to make fglrx into such a piece of shit05:44
lifelessone bug at a time05:44
wgrantPerhaps they're actually benevolent05:45
wgrantThey just make it unstable in order to improve FS crash handling cases.05:45
StevenKOr they just can't write drivers for their own hardware05:47
wgrantNever attribute to stupidity that which can be adequately explained by them being proprietary arses.05:47
StevenKAnd yet you say AMD are *better*? :-P05:48
wgrantIn some ways :)05:50
pooliewhat's fashionable these days for running lp dev?06:25
poolielxc, bare (precise) metal?06:26
wgrantLXC is in fashion, and there's even a script to set it up, but I'm not sure if it works.06:26
wgrantYellow is making it really easy to set up at present.06:26
pooliedoes it run ok on precise?06:26
wgrantThat's the target.06:27
poolieperhaps i'll just go with bare metal for now06:27
wgrantLP on precise?06:27
wgrantMostly, yes.06:27
wgrantA few tests fail, but it otherwise works.06:27
lifelesspoolie: the target for the paralleltests project is lxc (lucid) hosted on precise06:31
lifelesspoolie: the setuplxc script in tree should do a decent job of putting that together, starting from a precise 'bare metal'06:31
poolielifeless, i reinstalled my precise laptop a while ago so i have to choose between putting lp deps on the base os, or sometihng else06:32
poolieperhasp i'll try that06:32
pooliewould i be right in guessing less-oops.sh is obsolete now?06:47
=== Ursinha` is now known as Ursinha
=== Ursinha is now known as Guest37626
pooliesetuplxc is stuck at07:06
pooliembp@lptests's password:07:06
wgrantHm. It should automatically let your key in, AFAIK.07:07
poolieor rather, i'm not sure what password it's expecting07:07
wgrantBut it's the same as your normal system password.07:07
poolieif it is, ssh is rejecting it07:08
poolieFeb 20 07:05:19 localhost sshd[457]: User mbp not allowed because shell /usr/bin/zsh does not exist07:12
wgrantAh, heh.07:12
pooliei can fix that, but later07:12
wgrantOh no08:26
wgrantSurely not08:26
wgrantlifeless: Found out why the heat updater is slow08:34
wgrantlifeless: Goal time is 2s, as normal.08:34
wgrantThe initial query is 2.8s.08:35
wgrantSo it degrades to roughly 1 update per 3 seconds.08:35
wgrantAnd reads 154000 bug rows every 3 seconds.08:35
wgrantI bet if I fix that it updates the whole lot in 5 minutes.08:36
lifelesswhy is it reading 154K rows?08:36
wgrantProbably because it doesn't update duplicates, but the index doesn't exclude duplicates.08:37
lifelesswgrant: as in, why doesn't it have a LIMIT batch_size there ?08:37
poolielifeless, well, i pruned one small bit of cruft for you08:38
poolienot yet the timeline stuff though, due to EYAK08:38
lifelessthank you08:38
lifelesswgrant: uhm, you know we're running a branch of storm already....08:39
lifelesswgrant: so why you copy code?08:39
wgrantMmm, I guess.08:39
wgrantI prefer to be non-invasive where possible.08:40
lifelessdropping the non-null requirement on duplicates, and updating them appropriate, makes it fast08:40
lifelesslaunchpad_qastaging=> EXPLAIN ANALYZE SELECT id FROM bug WHERE (heat_last_updated IS NULL OR heat_last_updated < '2012-02-13')  LIMIT 1;08:40
lifelessTime: 1.906 ms08:40
wgrantlifeless: What if you add back the duplicateof and leave the LIMIT 1?08:42
lifeless7.7 seconds, table scan08:42
lifelesswith dup is null and order by heat_last_updated nulls last -> 2.2 sec08:42
wgrantI think we probably just fix the index to be duplicateof IS NULL.08:43
* wgrant tries.08:43
lifelessdid you get the actual results as well ?08:43
lifelessthere is a pattern, when you see a big slow scan even with a limit08:44
wgrantOh, there's meant to be an ORDER BY id there too08:44
wgrantMissed that08:44
wgrantJust to probably make it even slower.08:44
lifelessnah, not that08:44
wgrantI didn't get the results.08:44
wgrantI know08:44
wgrantBut thought I should note it.08:44
lifelessso, ordering by the index will force it to use it08:44
lifelessthe reason its slow is that it is finished08:45
lifelessSELECT id FROM bug WHERE duplicateof IS NULL AND (heat_last_updated IS NULL OR heat_last_updated < '2012-02-13')  order by heat_last_updated desc LIMIT 1;08:45
lifeless id08:45
lifeless(0 rows)08:45
lifelesswgrant: it is slow, and consulting all rows, because it can't fulfill the request; even when limited08:45
wgrantHah, true.08:46
lifelesswgrant: it has an estimate of 155K rows which is bong; it *is* examining all million rows08:46
lifelessso, I think there are two bugs: if it is not limiting its results to the current batch size, that is bong.08:47
lifelessAnd if it continues to try to do shit when nothing is returned, that is bong.08:47
lifelesswgrant: this is the same slowness that batches that run past the end of big data sets like BPR exhibit08:47
lifelesswgrant: where it suddenly goes off into lala land and reads through to the end of the table08:47
wgrantI think it is limiting, actually, I misread.08:48
lifelessok cool08:48
lifelessin which case, this is a nuisance but also a symptom - it should just stfu and stop :)08:48
wgrantBut all this would not be an issue if the index was right.08:48
lifelessthe index is fine08:49
lifelesschange the query to have order by heat_last_updated08:49
stub3 bongs, a shit and lala land.08:49
lifelessthat will update the oldest rows first (which is strictly correct anyhow)08:49
wgrantlifeless: The index is less than ideal.08:49
wgrantBecause it has to do a bitmap heap scan to determine duplicateness.08:49
stubAvoiding order by heat_last_updated as that isn't stable ordering08:50
wgrantAnd it will have to read all those rows first.08:50
lifelesswgrant: I don't see a bitmap heat scan in the explain08:50
wgrantBecause they'll be older.08:50
wgrant Bitmap Heap Scan on bug  (cost=12576.08..141492.57 rows=154605 width=4) (actual time=2861.017..2861.017 rows=0 loops=1)08:50
wgrant   Recheck Cond: ((heat_last_updated IS NULL) OR (heat_last_updated < '2012-02-13 00:00:00'::timestamp without time zone))08:50
wgrant   Filter: (duplicateof IS NULL)08:50
wgrantThat looks like a bitmap heap scan filtering on duplicateof to me :)08:50
lifelessthat was without the limit right ?08:50
lifelessexplain analyze SELECT id FROM bug WHERE duplicateof IS NULL AND (heat_last_updated IS NULL OR heat_last_updated < '2012-02-13') LIMIT 100;08:51
lifeless                                                                      QUERY PLAN08:51
lifeless Limit  (cost=0.00..100.82 rows=100 width=4) (actual time=1261.132..1261.132 rows=0 loops=1)08:51
lifeless   ->  Seq Scan on bug  (cost=0.00..155602.61 rows=154338 width=4) (actual time=1261.131..1261.131 rows=0 loops=1)08:51
lifeless         Filter: ((duplicateof IS NULL) AND ((heat_last_updated IS NULL) OR (heat_last_updated < '2012-02-13 00:00:00'::timestamp without time zone)))08:51
wgrantWith the limit it seq scans here08:51
lifeless Total runtime: 1261.219 ms08:51
wgrantWhich is hardly better.08:51
lifelessshrug, I'm fine with you improving it.08:51
lifelessJust saying, doesn't seem terrible given there are no rows08:52
wgrantSo, it either has to do a seq scan or it has to do an index scan.08:52
wgrantIf it does a seq scan it's probably going to take forever.08:52
stubIf we make the index partial, we have to ensure that all of the queries also have the duplicateof IS NULL clause08:52
wgrantIf it does an index scan, it has every dupe bug ever earlier on in the index.08:52
wgrantstub: All one query? :)08:53
lifelessstub: tis already partial08:53
wgrantIt's not partial.08:53
lifelessoh, not its not08:53
wgrantBut the one query that uses it will work if it's partial.08:53
lifelessRight, I should sleep.08:53
wgrantThat's why I want it partial :)08:53
stub    "bug__heat_last_updated__idx" btree (heat_last_updated)08:53
wgrantAnyway, I'm right, will submit DB patch with a few more indices later.08:53
* wgrant dines.08:53
lifelessits very odd that its not using the index today08:54
lifelessas the index is a superset of the data needed; it must think there are an overwhelming number of stale-hat duplicates08:54
lifelesswgrant: I suggest changing the code to update the heat on duplicates.08:54
lifelesswgrant: make it simpler, leave the index as-is08:54
lifelesswgrant: (yes, the update will be trivial..)08:55
stubAs there are 0 rows matching the clause, there should be 0 rows in the stats matching that clause. So the planner should think that, if they exist, they are unlikely and hit the indexes.08:56
lifelesswgrant: so yea,08:57
lifelessselect id, duplicateof, heat, heat_last_updated from bug where heat_last_updated in (select min(heat_last_updated) from bug);08:57
lifeless   id   | duplicateof | heat |     heat_last_updated08:57
lifeless 199626 |      199600 |    0 | 2010-05-28 17:50:04.05511408:57
lifeless(1 row)08:57
lifelesswe've been carefully shoving all the duplicate rows to the front of the desired index08:57
lifelessstub : but the planner doesn't know this08:57
lifelessstub: what it knows is that the index *starts* with a lot of data - 196K rows -08:58
stublifeless: I'm talking from the pov of the planner. It has to assume that the rows might be there, and that they are uncommon because they are not in the stats, so index lookups would be a win unless it needs to scan for some other reason.08:58
lifelessstub: me too08:58
lifelessstub: the thing is, they are common :)08:58
lifelessstub: the first 196K rows in the index are for duplicateof is null bugs08:59
pooliesetuplxc has new doctests?08:59
lifelesswgrant: updating duplicates would be more in line with using this as an occasional re-fresh-the-data script too - we might not always have duplicate imply 0, so this would remove a booby trap.08:59
lifelessstub: select count(*) from bug where heat_last_updated < '2012-02-13';09:00
lifeless count09:00
lifeless 19609409:00
stubOh right.09:02
lifelessso I think the planner is more or less saying '1/5 of the bugs in the table are relevant, which means I probably will find what they want on the first page -> scan'09:03
lifelessof course, then it gets horribly disappointed :)09:03
wgrantlifeless: That's another option.09:04
lifelesswgrant: I favour it, for the reasons I mention above09:04
wgrantGlad you saw the light about the index :)09:04
stubIts saying there are 196094 bugs where heat_last_updated < '2012-02-13', and zero bugs where heat_last_updated is null. But it is too stupid to know that there are 0 bugs where head_last_updated is null or < '2012-02-13'09:04
lifelessstub: s/heat_last_updated/duplicateof/ :P and yes.09:05
wgrantstub: The assumption in that second sentence is false.09:05
wgrantWhat lifeless said.09:05
lifelesswgrant: well, I see that the index isn't performing, I don't think we should change it, all things considered.09:05
lifelessanyhoo; i leave you and stub to debate it :> I'm offtosleep09:05
wgrantAh, crap.09:06
wgrantThat will probably need a DB patch.09:06
lifelesswgrant: what will?09:07
wgrantOr I workaround it by wrapping the calculate_bug_heat calls with a guard for dupeness.09:07
wgrantlifeless: calculate_bug_heat doesn't return 0 for dupes.09:07
wgrantThat's implemented in updateHeat09:07
lifelesswgrant: you wouldn't just call updateHeat(bug) ?09:07
wgrantlifeless: It currently uses RS.set()09:08
wgrantI guess this will still be a thousand times faster.09:08
wgrantSo could just use updateHeat09:08
stubthink I'm on the wrong query09:08
lifelessI mean, we're doing two things09:08
lifelessa) moving to update-once, ever, so not caring about 'older than one week' rather 'older than constant value'09:08
lifelessand b) making the operation decently efficient09:09
lifelesswgrant: or we could store non-zero heat for duplicates09:09
lifelesswgrant: I don't think it would break anything09:10
wgrantlifeless: That's true.09:10
lifelessIt has always seemed odd to me that a bug suddenly gets 0 heat when it becomes a dupe; dupes are filtered from results, so the heat should be orthogonal; and if someone searches for bugs including dupes, sorted by heat...09:10
wgrantWould remove a fair chunk of the remaining heat code09:10
wgrant(ie. 5 lines)09:10
lifelesswhy would we shove all the dupes to the bottom of the list09:10
lifelesshi mrevell09:11
=== almaisan-away is now known as al-maisan
wgrantSo, I'll remove the dupe => 0, and remove the non-dupe filter?09:11
lifelessmrevell: I've been meaning to catchup with you, but ETERRIBLETIMING09:11
lifelesswgrant: that works for me; see if you can convince yourrandomreviewer of the sanity of it ;)09:11
lifelesswgrant: you should also land either a knob, or a hard coded value, to replace the '1 week old' thing, unless you've done that already.09:12
adeuringgood morning09:13
wgrantlifeless: I haven't. Might do it in the same branch.09:13
wgrantA flag to set the earliest valid timestamp, if null then nothing happens.09:13
lifeless-> be09:15
thumpernight wgrant09:17
wgrantNot me, lifeless :)09:17
nigelbmeh, wgrant as no days and nights. he's awake throughout.09:19
mrevelllifeless, I'm available 22.30 UTC my Monday (11.30 your Tuesday, I believe). Does that work for you?09:23
StevenKbigjools: But only because Queenslanders wouldn't know what daylight savings time was if it bit them on the bum. :-)09:39
bigjoolsStevenK: quite!09:46
bigjoolsStevenK: I am quite happy with that though, means I stay closer to UK time09:46
=== al-maisan is now known as almaisan-away
=== almaisan-away is now known as al-maisan
czajkowskidaft question time, I do aplogise in advance14:01
czajkowskiif a  person requests ownership of a project and the registery are already the owners and seems to have some clue as to what they are talking about and an interest in helping the project14:02
czajkowskiis it ok to hand it over once fully checking they will maintain it?14:02
flacosteczajkowski: yes14:08
czajkowskiflacoste: aloha there :)14:09
czajkowskisomeone wants to take over ownership of Mandriva14:09
flacosteczajkowski: note that Mandriva is a distribution, and what you can do with this in LP is kind of limited14:19
flacostedistribution not using Soyuz14:19
flacostemainly you can only track bugs14:19
flacostewhich doesn't make sense here since Mandriva doesn't use LP for bug tracking :-)14:19
czajkowskiflacoste: https://answers.launchpad.net/launchpad/+question/18806414:19
czajkowskiflacoste: which is why I'm kinda confused and trying to work  it out, will get there eventually :)14:20
flacosteczajkowski: seems like a reasonable request, what is interesting is that he thinks that the Mandriva community would use LP for project planning, like the derivative he's involve dwith14:23
czajkowskiI did meet one of the folks leading the derivative at FOSDEM and he was asking how useful LP was. So maybe there is a plan B14:23
=== al-maisan is now known as almaisan-away
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
=== salgado is now known as salgado-lunch
=== salgado-lunch is now known as salgado
czajkowskiI'm really not sure how to asnwer this question or if even is a lp Question : https://answers.launchpad.net/launchpad/+question/18809417:51
rick_hczajkowski: yea, that's a major 'not applicable' to LP. Might suggest they try ask ubuntu if they've having issues with getting some PHP magic to work with ubuntu versios of php/apache.17:55
czajkowskirick_h: thanks17:55
czajkowskiwant to start on a clena page tomorrow so trying to clear up the last few17:55
czajkowskibene looking at that trying to work it out17:55
rick_hyea, basically if register globals is on, then things sent in a POST request to the server should be auto variables in his script and it's not working. but that stuff has been so bad practice for so long, it might just not even work in 5.3 I don't know17:56
* rick_h has php dev flashbacks ...shudder 17:56
czajkowskiI was wondering if people knew the reasons behind the lack of opera support on LP - https://answers.launchpad.net/launchpad/+question/18820018:02
lifeless / womenpower18:02
czajkowskilifeless: while I'd agreew ith you, writing that on a questions page isn't really going to be helpful now is it :)18:05
czajkowskiand the question shall remain open and I dont like open things in my queue :)18:05
* czajkowski has beaten RT into submission today 18:05
rick_hczajkowski: we've got a bug for the opera issue and I hope to take a peek at it, as we'll need it to fix IE8 support as well, so it's not that we're not going to fix it. Just not yet18:07
czajkowskiok that seems more of a reasonable answer to give someone18:08
rick_hczajkowski: yea, looking for the bug now, thought I was watching it18:08
lifelessczajkowski: so, opera isn't in our list of target browsers.18:08
lifelessczajkowski: its not in the list because (usually) what works for chromium (which is in the list) works for it, and we don't have the resources to test all browsers; opera isn't in the top-3 by volume browsers out there.18:09
lifelessczajkowski: I think its a fine answer to give, its true :). Also, please don't commit to us fixing opera, because chances are we won't, unless or until someone steps up and maintains opera support as a volunteer.18:10
lifelesslet me forward you the stakeholders thread on this18:12
czajkowskilifeless: thanks18:17
lifelessczajkowski: there was also a related discussion, on -dev I think, about how YUI no longer categorise browers the same way18:25
czajkowskithanks for the mail18:25
czajkowskiright time for some foods and relaxing befor eI switch brain over to locoteams work18:26
lifelessflacoste: can you hear me ?20:49
lifelessflacoste: http://bazaar.launchpad.net/~canonical-launchpad-branches/pybars/trunk/view/head:/pybars/_compiler.py21:07
=== salgado is now known as salgado-afk
flacostelifeless: ISP woes again?21:23
lifelessADSL apparently stands for approximately down standard link21:28
lifelessflacoste: http://www.yuiblog.com/blog/2011/07/12/gbs-update/#grades-deprecated is what I was babbling about21:35
flacostelifeless: yes, i saw, but their main page still explains the three tier grade approach, they just don't specify which browser gets which experience21:48
flacostebecause that should be left to each team to dictate21:48
flacostethey just specify which browsers they test21:48
flacostei think for us, it still makes sense21:48
flacostesince we are one such team that has to decide of the experience users get based on their browser and our resources to support it21:48
mrevellHey lifeless. Did you want to talk today?22:11
lifelessmrevell: sometime, but not today ;)22:16
lifelessmrevell: i have to pop out for a bit, and it's already way late for you22:16
mrevelllifeless, Okay, great :) I shall go to bed.22:17
mrevellNight all22:17
* wgrant needs opinions.22:59
wgrantBug #933911 is somewhat qa-bad22:59
_mup_Bug #933911: Remove PersonLocation-related code <qa-needstesting> <tech-debt> <users> <Launchpad itself:Fix Committed by salgado> < https://launchpad.net/bugs/933911 >22:59
wgrantBecause https://qastaging.launchpad.net/~/+editlocation doesn't preset its sole field to the existing value.22:59
wgrantI suspect we don't care enough to block things.23:00
thumperare we ever going to get ARM recipe builds?23:09
wgrantThey're no different from normal ARM PPA builds.23:09
StevenKthumper: If the PPA the recipe is built into supports ARM, you'll get it.23:13
wgrantAh, crap.23:14
* wgrant curses cocoplum to hell.23:14
lifelesswgrant: 'meh' (+editlocation)23:17
wgrantlifeless: Thanks,.23:17
thumperStevenK: how do you get a ppa to support arm?23:44
bigjoolsadmin option23:45
wgrantAh, *ning bigjools.23:45
StevenKbigjools: Packing furiously?23:45
bigjoolsyes. I now have my laptop in bed to catch up on email before I sleep23:46
bigjoolsgetting some snorts from the missus23:47
bigjoolswgrant: nice glob23:47
StevenKThe only thing that glob doesn't support is afternoon23:52
wgrantIt's not afternoon anywhere important :)23:54

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!