[00:19]  * StevenK takes ILaunchBag out the back, shoots it in the head, and then stabs it for good measure.
[00:34]  * mwhudson cheers StevenK on
[00:34] <mwhudson> StevenK: for real?  or is that just wishful thinking?
[00:35] <StevenK> mwhudson: Wishful thinking
[00:35] <mwhudson> boo
[01:16] <wgrant> Damn
[01:16] <wgrant> branch is down more than 90%, but it's still there :/
[02:39] <lifeless> http://dilbert.com/strips/comic/2007-11-26/
[03:29] <lifeless> wgrant: 100000 loops, best of 3: 7.32 usec per loop
[03:31] <lifeless> bah, typo
[03:40] <lifeless> ah, thats better
[03:40] <lifeless> :!bash ./profile
[03:40] <lifeless> 10 loops, best of 3: 21.7 msec per loop
[03:41] <wgrant> lifeless: Heh, that's slightly less implausible.
[03:42] <wgrant> Is that compile?
[03:44] <lifeless> pybars
[03:44] <lifeless> 10 loops, best of 3: 21.9 msec per loop
[03:44] <lifeless> pystache
[03:44] <lifeless> 10 loops, best of 3: 30.8 msec per loop
[03:46] <wgrant> lols
[03:55] <lifeless> comfortably faster b/4 optimisation
[03:56] <lifeless> could do 1500 items of that scale without worry within a second, I suspect
[03:56] <lifeless> will want some detailed tuning
[03:59] <wgrant> The previous timings were compile, I assume?
[04:00] <lifeless> no
[04:00] <lifeless> running the same template
[04:00] <lifeless> but with no data
[04:00] <lifeless> because lp.cache != what we feed the template
[04:00] <lifeless> so all the top level lookups found nothing
[04:01] <wgrant> 1500 * 30.8 > 1000
[04:01] <lifeless> thats pystache
[04:01] <wgrant> 1500 * 21.9 > 1000
[04:01] <lifeless> you are forgetting the /75
[04:01] <wgrant> Oh, so that's the template for the whole list?
[04:02] <lifeless> yes
[04:02] <wgrant> (also, lpnet average down to 395% from the 560% it was 2 weeks ago)
[04:31] <StevenK> wgrant: Do you want to review https://code.launchpad.net/~stevenk/launchpad/no-active-for-dsd-spr/+merge/93762 ?
[04:33] <wgrant> StevenK: r=me
[04:33] <wgrant> So, that's OOPS #3 (not #2 as I thought earlier) fixed.
[04:34] <wgrant> If you fix #1 (easy) and #2 (probably trivial) as well, we'll be at around 100 exceptions per day.
[04:34] <wgrant> And #4 isn't real
[04:35] <wgrant> StevenK: Actually
[04:35] <StevenK> wgrant: Hmm?
[04:35] <wgrant> Mm, I guess it's fine.
[04:35] <wgrant> Since it picks the most recent.
[04:35] <wgrant> And filters by version
[04:36] <wgrant> So there shouldn't be an issue with too many or non-latest resolds.
[04:36] <wgrant> results
[04:36] <StevenK> Right
[04:36]  * StevenK looks for our #1 OOPS
[04:36] <wgrant> It's None: None
[04:36] <wgrant> Which is usually log.warning or log.error
[04:36] <wgrant> In most cases it's garbo whinging that a task timed out.
[04:36] <wgrant> Can probably be demoted.
[04:37] <StevenK> Ah, bug 888049
[04:37] <_mup_> Bug #888049: garbo-frequently logged an oops <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/888049 >
[04:37] <wgrant> Yeah
[04:38] <wgrant> gnargh I hate security proxies breaking object identity.
[04:38] <stub> Garbo 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 lists
[04:38] <wgrant> stub: Mm
[04:38] <wgrant> We care that it keeps up in the end.
[04:39] <wgrant> At present to care that it keeps up daily we have to put it in garbo-daily.
[04:39] <wgrant> When in fact we may want to do it -hourly, but don't care if it lags for two hours.
[04:39] <StevenK> Or more, thanks to the backups
[04:39] <wgrant> Right
[04:39] <stub> Yes, 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:40] <stub> Backups were an issue, and we fixed that.
[04:40] <stub> They where a problem
[04:40] <wgrant> They still are AFAIK
[04:40] <stub> Backups 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:41] <wgrant> I thought that didn't matter.
[04:41] <StevenK> The OOPSes don't look like a problem of not running
[04:41] <StevenK> They are hitting the slice limit and being killed
 [BugHeatUpdater] Task aborted after 3299 seconds.
[04:42] <wgrant> Ah
[04:42] <wgrant> keeps getting blocked by librariangc and autovacuum now :/
[04:42] <wgrant> Instead of backups.
[04:42] <wgrant> But yes, bugheatupdater is terrible.
[04:42] <wgrant> I'm not sure why.
[04:43] <stub> librariangc? That is a new one. How is that blocking? Long running transactions?
[04:43] <wgrant> But the whole lot often get blocked by autovacuum for an hour
[04:43] <wgrant> Long running transactions on both counts, yeah
[04:43] <wgrant> 2012-02-20 02:53:23 INFO    [DuplicateSessionPruner] Blocked on 1:42:21.965885 old xact postgres@launchpad_prod_3/25895 - <HIDDEN>.
[04:43] <wgrant> 2012-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] <stub> oh... librariangc is a victim, not a cause
[04:43] <wgrant> 2012-02-20 00:02:06 INFO    [BugHeatUpdater] Blocked on 1:07:30.239287 old xact librariangc@launchpad_prod_3/32758 - <IDLE>.
[04:43] <wgrant> Possibly true, indeed.
[04:44] <StevenK> Right, so it's using self.log.warn()
[04:44] <stub> So we can silence these (don't report a task timeout if we got blocked for reasons beyond our control)
[04:45] <stub> Or we can make dblooptuner ignore autovacuum, which scares me a little.
[04:45] <wgrant> Perhaps we record the total time each task has been blocked.
[04:45] <StevenK> stub: My plan was to fix looptuner to not warn, so it stops causing >100 OOPSes a day
[04:45] <wgrant> And if it's more than $threshold, don't warn.
[04:46] <stub> That is easy enough to do IIRC
[04:46] <stub> We can go with that.
[04:46] <stub> Monitoring long running transactions can be done better than watching batch jobs produce errors
[04:47] <StevenK> Haha
[04:49] <nigelb> haha, I just read flacoste's email babout serial tab openers team. lol.
[04:50] <StevenK> nigelb: Did you see the cricket? :-P
[04:50] <wgrant> stub: That BranchLookup.getByUniqueName fix freed 1.5 cores on wildcherry.
[04:51] <wgrant> Which might almost mean that we're not screwed if we have to failover.
[04:51] <nigelb> StevenK: Nope, been offline helping run an  conference.
[04:51] <StevenK> nigelb: Aus 5/288, India 178
[04:51] <nigelb> fuuuuu.
[04:51] <nigelb> now?
[04:51] <wgrant> Heh
[04:51] <StevenK> That was last night
[04:52] <nigelb> Ah.  :-P
[05:50] <wgrant> In some ways :)
[06:25] <poolie> what's fashionable these days for running lp dev?
[06:26] <poolie> lxc, bare (precise) metal?
[06:26] <wgrant> LXC is in fashion, and there's even a script to set it up, but I'm not sure if it works.
[06:26] <wgrant> Yellow is making it really easy to set up at present.
[06:26] <poolie> hm
[06:26] <poolie> does it run ok on precise?
[06:27] <wgrant> That's the target.
[06:27] <poolie> perhaps i'll just go with bare metal for now
[06:27] <wgrant> Oh
[06:27] <wgrant> LP on precise?
[06:27] <wgrant> Mostly, yes.
[06:27] <wgrant> A few tests fail, but it otherwise works.
[06:31] <lifeless> poolie: the target for the paralleltests project is lxc (lucid) hosted on precise
[06:31] <lifeless> poolie: the setuplxc script in tree should do a decent job of putting that together, starting from a precise 'bare metal'
[06:32] <poolie> lifeless, i reinstalled my precise laptop a while ago so i have to choose between putting lp deps on the base os, or sometihng else
[06:32] <poolie> perhasp i'll try that
[06:32] <poolie> *setuplxc
[06:47] <poolie> would i be right in guessing less-oops.sh is obsolete now?
[07:06] <poolie> setuplxc is stuck at
[07:06] <poolie> mbp@lptests's password:
[07:07] <wgrant> Hm. It should automatically let your key in, AFAIK.
[07:07] <poolie> or rather, i'm not sure what password it's expecting
[07:07] <wgrant> But it's the same as your normal system password.
[07:08] <poolie> if it is, ssh is rejecting it
[07:08] <wgrant> :/
[07:12] <poolie> ok
[07:12] <poolie> Feb 20 07:05:19 localhost sshd[457]: User mbp not allowed because shell /usr/bin/zsh does not exist
[07:12] <wgrant> Ah, heh.
[07:12] <poolie> i can fix that, but later
[08:26] <wgrant> Oh no
[08:26] <wgrant> Surely not
[08:34] <lifeless> ?
[08:34] <wgrant> lifeless: Found out why the heat updater is slow
[08:34] <wgrant> lifeless: Goal time is 2s, as normal.
[08:35] <wgrant> The initial query is 2.8s.
[08:35] <wgrant> So it degrades to roughly 1 update per 3 seconds.
[08:35] <wgrant> And reads 154000 bug rows every 3 seconds.
[08:36] <wgrant> I bet if I fix that it updates the whole lot in 5 minutes.
[08:36] <lifeless> why is it reading 154K rows?
[08:37] <wgrant> Probably because it doesn't update duplicates, but the index doesn't exclude duplicates.
[08:37] <lifeless> wgrant: as in, why doesn't it have a LIMIT batch_size there ?
[08:38] <poolie> lifeless, well, i pruned one small bit of cruft for you
[08:38] <poolie> not yet the timeline stuff though, due to EYAK
[08:38] <lifeless> thank you
[08:39] <lifeless> wgrant: uhm, you know we're running a branch of storm already....
[08:39] <lifeless> wgrant: so why you copy code?
[08:39] <wgrant> Mmm, I guess.
[08:40] <wgrant> I prefer to be non-invasive where possible.
[08:40] <lifeless> dropping the non-null requirement on duplicates, and updating them appropriate, makes it fast
[08:40] <lifeless> launchpad_qastaging=> EXPLAIN ANALYZE SELECT id FROM bug WHERE (heat_last_updated IS NULL OR heat_last_updated < '2012-02-13')  LIMIT 1;
[08:40] <lifeless> Time: 1.906 ms
[08:42] <wgrant> lifeless: What if you add back the duplicateof and leave the LIMIT 1?
[08:42] <lifeless> 7.7 seconds, table scan
[08:42] <wgrant> Yep
[08:42] <lifeless> with dup is null and order by heat_last_updated nulls last -> 2.2 sec
[08:43] <wgrant> I think we probably just fix the index to be duplicateof IS NULL.
[08:43]  * wgrant tries.
[08:43] <lifeless> erm
[08:43] <lifeless> actually
[08:43] <lifeless> did you get the actual results as well ?
[08:44] <lifeless> there is a pattern, when you see a big slow scan even with a limit
[08:44] <wgrant> Oh, there's meant to be an ORDER BY id there too
[08:44] <wgrant> Missed that
[08:44] <wgrant> Just to probably make it even slower.
[08:44] <lifeless> nah, not that
[08:44] <wgrant> I didn't get the results.
[08:44] <wgrant> I know
[08:44] <wgrant> But thought I should note it.
[08:44] <lifeless> so, ordering by the index will force it to use it
[08:45] <lifeless> (often)
[08:45] <lifeless> the reason its slow is that it is finished
[08:45] <lifeless> tada.
[08:45] <lifeless> SELECT 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>  id
[08:45] <lifeless> ----
[08:45] <lifeless> (0 rows)
[08:45] <lifeless> wgrant: it is slow, and consulting all rows, because it can't fulfill the request; even when limited
[08:46] <wgrant> Hah, true.
[08:46] <lifeless> wgrant: it has an estimate of 155K rows which is bong; it *is* examining all million rows
[08:47] <lifeless> so, I think there are two bugs: if it is not limiting its results to the current batch size, that is bong.
[08:47] <lifeless> And if it continues to try to do shit when nothing is returned, that is bong.
[08:47] <lifeless> wgrant: this is the same slowness that batches that run past the end of big data sets like BPR exhibit
[08:47] <lifeless> wgrant: where it suddenly goes off into lala land and reads through to the end of the table
[08:48] <wgrant> I think it is limiting, actually, I misread.
[08:48] <lifeless> ok cool
[08:48] <wgrant> Yeah
[08:48] <lifeless> in which case, this is a nuisance but also a symptom - it should just stfu and stop :)
[08:48] <wgrant> But all this would not be an issue if the index was right.
[08:49] <lifeless> the index is fine
[08:49] <lifeless> change the query to have order by heat_last_updated
[08:49] <stub> 3 bongs, a shit and lala land.
[08:49] <lifeless> that will update the oldest rows first (which is strictly correct anyhow)
[08:49] <wgrant> lifeless: The index is less than ideal.
[08:49] <wgrant> Because it has to do a bitmap heap scan to determine duplicateness.
[08:50] <stub> Avoiding order by heat_last_updated as that isn't stable ordering
[08:50] <wgrant> And it will have to read all those rows first.
[08:50] <lifeless> wgrant: I don't see a bitmap heat scan in the explain
[08:50] <wgrant> Because 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] <wgrant> That looks like a bitmap heap scan filtering on duplicateof to me :)
[08:50] <lifeless> that was without the limit right ?
[08:51] <lifeless> explain 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 PLAN
[08:51] <lifeless> -------------------------------------------------------------------------------------------------------------------------------------------------------
[08: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] <wgrant> With the limit it seq scans here
[08:51] <lifeless>  Total runtime: 1261.219 ms
[08:51] <wgrant> Which is hardly better.
[08:51] <lifeless> shrug, I'm fine with you improving it.
[08:52] <lifeless> Just saying, doesn't seem terrible given there are no rows
[08:52] <wgrant> So, it either has to do a seq scan or it has to do an index scan.
[08:52] <wgrant> If it does a seq scan it's probably going to take forever.
[08:52] <stub> If we make the index partial, we have to ensure that all of the queries also have the duplicateof IS NULL clause
[08:52] <wgrant> If it does an index scan, it has every dupe bug ever earlier on in the index.
[08:53] <wgrant> stub: All one query? :)
[08:53] <lifeless> stub: tis already partial
[08:53] <wgrant> It's not partial.
[08:53] <lifeless> oh, not its not
[08:53] <wgrant> But the one query that uses it will work if it's partial.
[08:53] <lifeless> Right, I should sleep.
[08:53] <wgrant> That's why I want it partial :)
[08:53] <stub>     "bug__heat_last_updated__idx" btree (heat_last_updated)
[08:53] <wgrant> Anyway, I'm right, will submit DB patch with a few more indices later.
[08:53]  * wgrant dines.
[08:54] <lifeless> its very odd that its not using the index today
[08:54] <lifeless> as the index is a superset of the data needed; it must think there are an overwhelming number of stale-hat duplicates
[08:54] <lifeless> wgrant: I suggest changing the code to update the heat on duplicates.
[08:54] <lifeless> wgrant: make it simpler, leave the index as-is
[08:55] <lifeless> wgrant: (yes, the update will be trivial..)
[08:56] <stub> As 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:57] <lifeless> wgrant: so yea,
[08:57] <lifeless> select 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_updated
[08:57] <lifeless> --------+-------------+------+----------------------------
[08:57] <lifeless>  199626 |      199600 |    0 | 2010-05-28 17:50:04.055114
[08:57] <lifeless> (1 row)
[08:57] <lifeless> we've been carefully shoving all the duplicate rows to the front of the desired index
[08:57] <lifeless> stub : but the planner doesn't know this
[08:58] <lifeless> stub: what it knows is that the index *starts* with a lot of data - 196K rows -
[08:58] <stub> lifeless: 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] <lifeless> stub: me too
[08:58] <lifeless> stub: the thing is, they are common :)
[08:59] <lifeless> stub: the first 196K rows in the index are for duplicateof is null bugs
[08:59] <poolie> setuplxc has new doctests?
[08:59] <lifeless> wgrant: 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.
[09:00] <lifeless> stub: select count(*) from bug where heat_last_updated < '2012-02-13';
[09:00] <lifeless>  count
[09:00] <lifeless> --------
[09:00] <lifeless>  196094
[09:01] <czajkowski> Aloha
[09:02] <stub> Oh right.
[09:03] <lifeless> so 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] <lifeless> of course, then it gets horribly disappointed :)
[09:04] <wgrant> lifeless: That's another option.
[09:04] <lifeless> wgrant: I favour it, for the reasons I mention above
[09:04] <wgrant> Yep
[09:04] <wgrant> Glad you saw the light about the index :)
[09:04] <stub> Its 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:05] <lifeless> stub: s/heat_last_updated/duplicateof/ :P and yes.
[09:05] <wgrant> stub: The assumption in that second sentence is false.
[09:05] <wgrant> Right
[09:05] <wgrant> What lifeless said.
[09:05] <lifeless> wgrant: well, I see that the index isn't performing, I don't think we should change it, all things considered.
[09:05] <lifeless> anyhoo; i leave you and stub to debate it :> I'm offtosleep
[09:06] <wgrant> Night.
[09:06] <wgrant> Thanks!
[09:06] <wgrant> Ah, crap.
[09:06] <wgrant> That will probably need a DB patch.
[09:07] <lifeless> wgrant: what will?
[09:07] <wgrant> Or I workaround it by wrapping the calculate_bug_heat calls with a guard for dupeness.
[09:07] <wgrant> lifeless: calculate_bug_heat doesn't return 0 for dupes.
[09:07] <stub> https://pastebin.canonical.com/60572/
[09:07] <wgrant> That's implemented in updateHeat
[09:07] <lifeless> wgrant: you wouldn't just call updateHeat(bug) ?
[09:08] <wgrant> lifeless: It currently uses RS.set()
[09:08] <wgrant> I guess this will still be a thousand times faster.
[09:08] <wgrant> So could just use updateHeat
[09:08] <lifeless> yeah
[09:08] <stub> think I'm on the wrong query
[09:08] <lifeless> I mean, we're doing two things
[09:08] <lifeless> a) moving to update-once, ever, so not caring about 'older than one week' rather 'older than constant value'
[09:09] <lifeless> and b) making the operation decently efficient
[09:09] <lifeless> wgrant: or we could store non-zero heat for duplicates
[09:10] <lifeless> wgrant: I don't think it would break anything
[09:10] <mrevell> Hello
[09:10] <wgrant> lifeless: That's true.
[09:10] <lifeless> It 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] <wgrant> Would remove a fair chunk of the remaining heat code
[09:10] <wgrant> (ie. 5 lines)
[09:10] <lifeless> why would we shove all the dupes to the bottom of the list
[09:11] <lifeless> hi mrevell
[09:11] <wgrant> So, I'll remove the dupe => 0, and remove the non-dupe filter?
[09:11] <lifeless> mrevell: I've been meaning to catchup with you, but ETERRIBLETIMING
[09:11] <lifeless> wgrant: that works for me; see if you can convince yourrandomreviewer of the sanity of it ;)
[09:12] <lifeless> wgrant: 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:13] <adeuring> good morning
[09:13] <wgrant> lifeless: I haven't. Might do it in the same branch.
[09:13] <wgrant> A flag to set the earliest valid timestamp, if null then nothing happens.
[09:15] <lifeless> yah
[09:15] <lifeless> -> be
[09:15] <lifeless> d
[09:15] <wgrant> noight
[09:17] <thumper> night wgrant
[09:17] <wgrant> Not me, lifeless :)
[09:19] <nigelb> meh, wgrant as no days and nights. he's awake throughout.
[09:20] <wgrant> Heh
[09:23] <mrevell> lifeless, I'm available 22.30 UTC my Monday (11.30 your Tuesday, I believe). Does that work for you?
[09:39] <StevenK> bigjools: But only because Queenslanders wouldn't know what daylight savings time was if it bit them on the bum. :-)
[09:46] <bigjools> StevenK: quite!
[09:46] <bigjools> StevenK: I am quite happy with that though, means I stay closer to UK time
[14:01] <czajkowski> daft question time, I do aplogise in advance
[14:02] <czajkowski> if 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 project
[14:02] <czajkowski> is it ok to hand it over once fully checking they will maintain it?
[14:08] <flacoste> czajkowski: yes
[14:09] <czajkowski> flacoste: aloha there :)
[14:09] <czajkowski> thanks
[14:09] <flacoste> hi!
[14:09] <czajkowski> someone wants to take over ownership of Mandriva
[14:18] <flacoste> interesting
[14:19] <flacoste> czajkowski: note that Mandriva is a distribution, and what you can do with this in LP is kind of limited
[14:19] <flacoste> distribution not using Soyuz
[14:19] <flacoste> mainly you can only track bugs
[14:19] <czajkowski> nods
[14:19] <flacoste> which doesn't make sense here since Mandriva doesn't use LP for bug tracking :-)
[14:19] <czajkowski> flacoste: https://answers.launchpad.net/launchpad/+question/188064
[14:20] <czajkowski> flacoste: which is why I'm kinda confused and trying to work  it out, will get there eventually :)
[14:23] <flacoste> czajkowski: 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 dwith
[14:23] <czajkowski> nods
[14:23] <czajkowski> I 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 B
[17:51] <czajkowski> I'm really not sure how to asnwer this question or if even is a lp Question : https://answers.launchpad.net/launchpad/+question/188094
[17:55] <rick_h> czajkowski: 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] <czajkowski> rick_h: thanks
[17:55] <czajkowski> want to start on a clena page tomorrow so trying to clear up the last few
[17:55] <czajkowski> bene looking at that trying to work it out
[17:56] <rick_h> yea, 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 know
[17:56]  * rick_h has php dev flashbacks ...shudder
[18:02] <czajkowski> I was wondering if people knew the reasons behind the lack of opera support on LP - https://answers.launchpad.net/launchpad/+question/188200
[18:02] <lifeless> manpower
[18:02] <lifeless>  / womenpower
[18:05] <czajkowski> lifeless: while I'd agreew ith you, writing that on a questions page isn't really going to be helpful now is it :)
[18:05] <czajkowski> and the question shall remain open and I dont like open things in my queue :)
[18:05]  * czajkowski has beaten RT into submission today
[18:07] <rick_h> czajkowski: 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 yet
[18:08] <czajkowski> ok that seems more of a reasonable answer to give someone
[18:08] <rick_h> czajkowski: yea, looking for the bug now, thought I was watching it
[18:08] <lifeless> czajkowski: so, opera isn't in our list of target browsers.
[18:09] <lifeless> czajkowski: 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:10] <lifeless> czajkowski: 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:12] <czajkowski> nods
[18:12] <lifeless> let me forward you the stakeholders thread on this
[18:17] <czajkowski> lifeless: thanks
[18:25] <lifeless> czajkowski: there was also a related discussion, on -dev I think, about how YUI no longer categorise browers the same way
[18:25] <czajkowski> nods
[18:25] <czajkowski> thanks for the mail
[18:26] <czajkowski> right time for some foods and relaxing befor eI switch brain over to locoteams work
[18:26] <czajkowski> nn
[18:26] <lifeless> nn
[20:49] <lifeless> flacoste: can you hear me ?
[21:07] <lifeless> flacoste: http://bazaar.launchpad.net/~canonical-launchpad-branches/pybars/trunk/view/head:/pybars/_compiler.py
[21:23] <flacoste> lifeless: ISP woes again?
[21:28] <lifeless> ADSL apparently stands for approximately down standard link
[21:35] <lifeless> flacoste: http://www.yuiblog.com/blog/2011/07/12/gbs-update/#grades-deprecated is what I was babbling about
[21:48] <flacoste> lifeless: yes, i saw, but their main page still explains the three tier grade approach, they just don't specify which browser gets which experience
[21:48] <flacoste> because that should be left to each team to dictate
[21:48] <flacoste> they just specify which browsers they test
[21:48] <flacoste> i think for us, it still makes sense
[21:48] <flacoste> since we are one such team that has to decide of the experience users get based on their browser and our resources to support it
[21:59] <lifeless> kk
[22:11] <mrevell> Hey lifeless. Did you want to talk today?
[22:16] <lifeless> mrevell: sometime, but not today ;)
[22:16] <lifeless> mrevell: i have to pop out for a bit, and it's already way late for you
[22:17] <mrevell> lifeless, Okay, great :) I shall go to bed.
[22:17] <mrevell> Night all
[22:59]  * wgrant needs opinions.
[22:59] <wgrant> Bug #933911 is somewhat qa-bad
[22: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] <wgrant> Because https://qastaging.launchpad.net/~/+editlocation doesn't preset its sole field to the existing value.
[23:00] <wgrant> I suspect we don't care enough to block things.
[23:09] <thumper> hey
[23:09] <thumper> are we ever going to get ARM recipe builds?
[23:09] <wgrant> They're no different from normal ARM PPA builds.
[23:13] <StevenK> thumper: If the PPA the recipe is built into supports ARM, you'll get it.
[23:14] <wgrant> Ah, crap.
[23:14]  * wgrant curses cocoplum to hell.
[23:17] <lifeless> wgrant: 'meh' (+editlocation)
[23:17] <wgrant> lifeless: Thanks,.
[23:44] <thumper> StevenK: how do you get a ppa to support arm?
[23:45] <bigjools> admin option
[23:45] <wgrant> Ah, *ning bigjools.
[23:45] <StevenK> bigjools: Packing furiously?
[23:46] <bigjools> yes. I now have my laptop in bed to catch up on email before I sleep
[23:47] <bigjools> getting some snorts from the missus
[23:47] <bigjools> wgrant: nice glob
[23:52] <StevenK> The only thing that glob doesn't support is afternoon
[23:54] <wgrant> It's not afternoon anywhere important :)


[05:57] <CIA-28> ubiquity: superm1 * r3140 mythbuntu-ubiquity/ (debian/changelog ubiquity/frontend/mythbuntu_ui.py):
[05:57] <CIA-28> ubiquity: * Mythbuntu:
[05:57] <CIA-28> ubiquity:  - Don't prevent going forward in the UI if the connection test fails.
[05:57] <CIA-28> ubiquity:  It's no longer necessary for 9.04 to actually work. (LP: #343432)
[11:02] <mvo> a friend of mine just test the 9.04 beta on a system with window already installed and he got: http://people.ubuntu.com/~mvo/tmp/Bildschirmfoto-1.png in the partitioning step. is that intentional that it defaults to "use entire disk" in this case?
[11:08] <cjwatson> mvo: I think that's a bug - "side by side" should be the default if offered
[11:14] <mvo> cjwatson: do you want me to file it into LP? I guess I should wait until I can make him run it with debug in ubqiuity
[11:14] <cjwatson> yes please
[11:14] <cjwatson> (file it; obviously debug output would be good too)
[11:14] <cjwatson> I suspect it is easily reproducible though
[11:58] <CIA-28> debian-installer: cjwatson * r1074 ubuntu/debian/changelog: last commit closes LP: #345534
[12:29] <_ruben> man .. why is grub causing troubles on a large number of recent deployments .. getting fairly annoying .. installing onto pata flashdisks and also sata disks for storage
[12:29] <_ruben> both hardy and intrepid
[12:37] <CIA-28> debian-installer: cjwatson * r1075 ubuntu/debian/changelog: releasing version 20081029ubuntu29
[12:37] <mvo> I'm just testing a usb stick produced with usb-creator. when I try to install wine via apt-get it tells me "no space left on device" is that intentional, i.e. a known limitation  ? I(using the default options in usb-creator)
[12:38] <cjwatson> mvo: Evan's off this week and I'm not sure I know
[12:39] <cjwatson> might it depend on the amount of space you allocate for persistent data in usb-creator?
[12:39] <mvo> I think we selected 128mb (I have a intern doing some testing for me, I need to confirm to be 100% sure)
[12:39] <mvo> I will file a bug and just ask evan to close it if its intentional
[13:01] <CIA-28> ubiquity: cjwatson * r3141 ubiquity/ (debian/changelog debian/rules scripts/install.py):
[13:01] <CIA-28> ubiquity: Depend on grub | grub-pc, and don't remove grub-pc until after
[13:01] <CIA-28> ubiquity: grub-installer has had the chance to decide whether it wants to use it
[13:01] <CIA-28> ubiquity: (LP: #349835).
[13:29] <CIA-28> ubiquity: cjwatson * r3142 ubiquity/ (4 files in 2 dirs):
[13:29] <CIA-28> ubiquity: Add a compatibility wrapper for update-dev to ensure that it never
[13:29] <CIA-28> ubiquity: attempts to call 'udevadm trigger', which isn't necessary in ubiquity
[13:29] <CIA-28> ubiquity: and can cause problems (LP: #349937).
[13:45] <cody-somerville> cjwatson, btw, ppp-udeb is in main, not universe.
[13:53] <cjwatson> cody-somerville: so it is, but it's Priority: optional and therefore not used by default. If it's being pulled in for you then you must be doing something wrong
[13:53] <cjwatson> nothing depends on it
[13:54] <CIA-28> ubiquity: cjwatson * r3143 ubiquity/ (debian/changelog ubiquity/validation.py):
[13:54] <CIA-28> ubiquity: Permit dmraid-style /dev/mapper/* device names in advanced boot loader
[13:54] <CIA-28> ubiquity: selector, as well as disk and partition numbers over 9 (LP: #342354).
[13:54] <mvo> cjwatson: what is the right place in ubiquity to remove stuff that is on the livefs but should not be on the installed system? /var/lib/apt-xapian-index should be removed on install so that it can be re-created freshly with the full sources.list of the installed system
[13:59] <cjwatson> scripts/install.py - is that a directory?
[13:59] <mvo> yes
[13:59] <cjwatson> I don't have it on my system
[14:01] <cjwatson> mvo: will it be reindexed automatically or does ubiquity need to run something?
[14:01] <mvo> cjwatson: it will be re-indexed automatically when the next apt.cron.daily runs (I'm adding this now) or if synaptic detects its missing
[14:02] <mvo> http://paste.ubuntu.com/140714/
[14:02] <cjwatson> oh, I already had a different patch written
[14:02] <mvo> I put it in configure_apt
[14:02] <mvo> heh :)
[14:02] <mvo> ok
[14:03] <mvo> where did you put it? just out of curiosity
[14:03] <cjwatson> though I guess it's better in configure_apt than in configure_hardware where I put it
[14:04] <CIA-28> ubiquity: cjwatson * r3144 ubiquity/ (debian/changelog scripts/install.py):
[14:04] <CIA-28> ubiquity: Remove /target/var/lib/apt-xapian-index per Michael Vogt, since it needs
[14:04] <CIA-28> ubiquity: to be rebuilt based on the installed system's sources.list, and apt's
[14:04] <CIA-28> ubiquity: cron.daily script and/or synaptic will do this.
[14:04] <mvo> thanks
[14:05]  * mvo hugs cjwatson
[14:05] <cjwatson> np
[14:07] <cjwatson> thanks for the apt merge
[14:16] <mvo> np
[14:17] <mvo> I will upload new apt today, I was just merging some small apt.cron.daily fixes in
[14:22] <CIA-28> ubiquity: cjwatson * r3145 ubiquity/ (debian/changelog ubiquity/components/partman.py):
[14:22] <CIA-28> ubiquity: Preserve ordering of automatic partitioning choices when replacing them
[14:22] <CIA-28> ubiquity: with our customised strings (LP: #351547).
[14:35] <CIA-28> ubiquity: cjwatson * r3146 ubiquity/debian/changelog: typo
[15:16] <CIA-28> ubiquity: cjwatson * r3147 ubiquity/ (70 files in 2 dirs): Update translations from Launchpad.
[15:27] <CIA-28> ubiquity: cjwatson * r3148 ubiquity/ (d-i/manifest debian/changelog):
[15:27] <CIA-28> ubiquity: Automatic update of included source packages: apt-setup 1:0.37ubuntu11,
[15:27] <CIA-28> ubiquity: base-installer 1.98ubuntu4, console-setup 1.28ubuntu7, grub-installer
[15:27] <CIA-28> ubiquity: 1.36ubuntu5, hw-detect 1.71ubuntu6, partman-base 129ubuntu4,
[15:27] <CIA-28> ubiquity: partman-target 58ubuntu6.
[16:22] <cjwatson> superm1: your revision 2984 broke the indication of language support being missing for any language not on the CD. bug 337748
[16:23] <cjwatson> superm1: I think language-support-* should be treated specially instead
[16:24] <cjwatson> actually, it's more complicated than that, since language-pack-foo might be on the CD while language-support-foo might not be but it might still exist
[16:44] <CIA-28> ubiquity: cjwatson * r3149 ubiquity/debian/changelog: releasing version 1.12.0
[18:08] <superm1> cjwatson, oh man. considering it's more complicated than it first seems, feel free to revert it then and i'll put a workaround back in the factory process for it until a better solution is come up with
[18:09] <cjwatson> I was wondering if there might be something straightforward like extracting the full list of packages that actually exist from the live filesystem's apt cache
[18:10] <cjwatson> I say "straightforward"
[18:10] <cjwatson> (actually pain in arse because scripts/install.py configures apt up-front to only use /target)
[18:10] <cjwatson> oh, but the blacklisting code runs before that ... hmm
[18:11] <cjwatson> maybe then select_language_packs should check whether each package exists and only add it if so
[18:13] <cjwatson> superm1: something like http://paste.ubuntu.com/140842/ maybe
[22:45] <superm1> cjwatson, ill give that a shot, but i'd worry it's going to increase install time by iterating a large list again
[22:45] <CIA-28> oem-config: superm1 * r640 oem-config/ (debian/changelog gui/glade/step_language.glade):
[22:45] <CIA-28> oem-config: Change the number of columns in the language icon view to 5. This
[22:45] <CIA-28> oem-config: should make it fit in 1024x600 or at least very close. (LP: #347350)
[22:48] <cjwatson> superm1: wouldn't expect so, checking for existence in the cache should be really quick
[22:48] <cjwatson> oem-config> thanks, that's appreciated
[22:48] <superm1> cjwatson, yup np.  it was really bothering me and looked obv to fix
[22:49] <cjwatson> superm1: ideally I'd like to figure out how to make the padding less unnecessarily large
[22:49] <cjwatson> superm1: but I stared at GtkIconView for ages and couldn't see how to do that
[22:49] <superm1> cjwatson, yeah i was thinking the same thing, I figured there should be a lever for it's padding but it wasn't standing out
[23:00] <superm1> cjwatson, actually you know what.  that iv_size_req thing: if it's taken out, everything fits in 800x576 perfectly for me
[23:01] <superm1> cjwatson, evan said it was a hack to not show scrollbars in the code, but they're not showing anyway for me with it commented out
[23:01] <superm1> that's where the extra padding is coming from i think
[23:01] <cjwatson> huh, odd. Is that producing *internal* padding?
[23:02] <superm1> it's producing padding on the iconview
[23:02] <cjwatson> i.e. around each individual label?
[23:02] <superm1> ah that; no.
[23:03] <cjwatson> I think if that makes it fit in 800x576, that's good cause to take it out for now
[23:04] <cjwatson> we have revision control if we need to restore it later
[23:04] <superm1> ok i'll commit that too then.
[23:05] <cjwatson> cool, thanks
[23:05] <cjwatson> I was planning an oem-config upload tomorrow
[23:06] <superm1> in the process of going thru this, i caught a small crasher that happened going back and forth between pages too.  might want to double check for that before you upload if you can
[23:06] <superm1> submitted an apport on it
[23:06] <cjwatson> ok
[23:13] <CIA-28> oem-config: superm1 * r641 oem-config/ (debian/changelog lib/frontend/gtk_ui.py):
[23:13] <CIA-28> oem-config: * Remove old hack in gtk frontend to only show scrollbars on language
[23:13] <CIA-28> oem-config: selector when it would be larger than the desktop. With the hack taken
[23:13] <CIA-28> oem-config: out, the scrollbars aren't showing up on 800x576, which is likely the
[23:13] <CIA-28> oem-config: lowest supportable resolution.
[23:34] <TheMuso> cjwatson: I think that brltty and no keyboard bug is due to no udev loaded, so no USB keyboard modules loaded. I wonder whether that setup script should be moved to be after udev, assuming that this is possible before usplash loads...
[23:34]  * TheMuso has a look
[23:35] <TheMuso> Looks like not.
[23:43] <superm1> cjwatson, that ubiquity diff didn't appear to work properly in a test run, i'll think about it more, but feel free to revert the changeset that caused it to come back up if nothing comes up solution wise


[06:11] <monfraide> Hi everybody
[06:11] <monfraide> I need a hand to help me...
[06:17] <monfraide> Hi everybody
[06:17] <monfraide> someone here ?
[18:08] <Admiral> I'd like to change the login window settings, I'd like to use the "LightDM GTK+ Greeter Settings" because the provided app ("Login Window") does not allow to change fonts
[18:09] <Admiral> It is not functional though so I don't know what to do, I can't seem to find the .conf file anywhere, or rather, they are not consistent with the settings I'm choosing
[18:51] <Admiral> I'd like to change the login window settings, I'd like to use the "LightDM GTK+ Greeter Settings" because the provided app ("Login Window") does not allow to change fonts. It is not functional though so I don't know what to do, I can't seem to find the .conf file anywhere, or rather, they are not consistent with the settings I'm choosing.
[20:26] <fossfreedom> Admiral, the slick-greeter.conf file is in /etc/lightdm/slick-greeter.conf
[20:26] <fossfreedom> settings are as per the README https://github.com/linuxmint/slick-greeter
[20:27] <fossfreedom> but you need to be aware there are quite a few areas that are hard-coded "Ubuntu" - I raised this with upstream a while ago, but its waiting for someone to fix
[20:30] <Admiral> I managed to change backgrounds, theme, icons and all, it's just that the login settings application is lacking and the usual greeter settings app doesn't work. I doubt that I can't actually tweak what I want to tweak.
[20:31] <fossfreedom> What specifically are you trying to change Admiral ?
[20:35] <Admiral> I'm using Adapta as a theme, but Lato as a desktop font (by the way the desktop doesn't respect the set Interface fonts, it reverts to what I think is DejaVu Sans, on Solus Budgie desktop fonts would conform to Interface fonts as set in Budgie Settings, albeit after a logout-login cycle)
[20:36] <Admiral> and I'm using DMZ-White as a cursor, I'd like these settings to be applied to the greeter too
[20:38] <fossfreedom> Look like code changes will need to be made to slick-greeter to apply a specific cursor
[20:40] <Admiral> usually DMZ-White is the default cursor in the greeter though. It switches to the Breeze cursor (oh I forgot to say that I switched cursors on my desktop too), I assume because that's what the Adapta theme calls for.
[20:41] <Admiral> Maybe a workaround could be to switch cursors in the theme? This is not optimal but I guess that I have no other choice
[20:41] <Admiral> What about the desktop font issue? I'll show you what I mean:
[20:42] <fossfreedom> not sure how it works - breeze seems to override DMZ-White.  If you purge breeze then DMZ-White should be used.
[20:43] <Admiral> https://imgur.com/29nQ8ew
[20:45] <fossfreedom> what am I looking for in the picture?
[20:45] <Admiral> the desktop icons have different fonts
[20:45] <Admiral> compared to the titlebar and the menubar, which are the Interface fonts
[20:46] <Admiral> which I set to Lato Regular
[20:46] <Admiral> the icons seem to have DejaVu Sans
[20:46] <fossfreedom> That's nautilus - known issue with budgie-desktop-settings - you have to manually change the nautilus fonts
[20:46] <Admiral> where?
[20:47] <Admiral> fwiw, on Solus it correctly respects the setting, although you have to reboot what I gather is nautilus (the desktop handler)
[20:49] <fossfreedom> sounds like Solus has patched stuff
[20:50] <fossfreedom> dconf-editor and various fonts can be changed - look for "fonts" here for various schema's where you define them.  e.g. org.gnome.nautilus.desktop https://github.com/UbuntuBudgie/budgie-welcome/blob/master/data/config/material-vimix-style.json
[20:53] <Admiral> it worked, thanks!
[20:53] <fossfreedom> yw


[01:49] <mrgoodcat> rick_h_: will be too busy gambling to cry
[01:49] <mrgoodcat> maybe drink himself to sleep
[05:06] <rick_h_> mrgoodcat: would love to add search/etc to the python cli now
[05:06] <rick_h_> mrgoodcat: just not needed it yet
[06:22] <mrgoodcat> rick_h_: I'll work on the python module tomorrow
[07:04] <rick_h_> mrgoodcat: all good
[07:05] <rick_h_> do what works for you
[12:35] <cmaloney> Good morning
[19:24] <rick_h_> wooo, heading home
[19:37] <rick_h_> oh right, everyone is at penguicon
[19:37] <rick_h_> hope that's going well
[21:40] <cmaloney> oing well
[21:40] <cmaloney> hope the flight is uneventful
[21:41] <mrgoodcat> internet on the plane?


[08:57] <mrqtros> Hi all
[08:58] <mrqtros> Did someone use DownloadManager? I can't understand why there is no any system-wide indication of download progress (I've seen it before, on older OS versions)
[09:01] <popey> there is
[09:01] <popey> there's a transfer indicator
[09:02] <popey> not sure everything shows there - take a look at podbird, i think that uses download manager
[09:13] <mrqtros> hello, popey)
[09:13] <popey> hey
[09:14] <mrqtros> Sadly I can't see it
[09:14] <mrqtros> mb smth wrong in my app, I'll try clean example from scratch
[09:14] <popey> mrqtros: the transfer indicator only appears when a download is happening
[09:14] <mrqtros> popey ep, I even receive progress indication signals, from 0 to 100
[09:15] <popey> podbird does use download manager it seems
[09:15] <mrqtros> yep*
[09:15] <popey> ok
[09:15] <popey> (I don't know much about this, sorry)
[09:15] <mrqtros> But no any visualization from OS
[09:16] <mrqtros> Downloading podbird... )
[09:19] <mrqtros> popey do use progress of download only in app or in system notifications too?
[09:19] <mrqtros> In podbird)
[09:29] <mrqtros> popey sorry I mean "do you see (!) progress only in app or in system "tray" too?"
[09:29] <mrqtros> popey of course you don't use it :)
[09:36] <popey> mrqtros: i dont see it, not sure what makes stuff appear in the indicator
[09:36] <mrqtros> popey strange) Mb you know then where I can find newly downloaded file?
[12:47] <newsages> hiii   hola
[12:48] <newsages> question : i can use U1DB from my C++ plugin? how to?
[13:44] <foo-script> Hi pals :)
[14:00] <efes> hello :)
[14:01] <efes> Guys, I get segfault from emulator, literally adbd, when I try to run any of the emulators. Default installation, everything taken from the repo, no alterations in Ubuntu SDK.
[14:01] <efes> Log: http://pastebin.ubuntu.com/10800524/
[14:01] <bzoltan> efes:  what release you are on and what channel the emulator was created? Did you try other channels?
[14:03] <bzoltan> efes:  without knowing much about your issue I wold remove the emulator and create a new one from the devel-proposed
[14:03] <efes> bzoltan: Do not understand your question. Emulator fails for i386 devel and i386 stable
[14:03] <efes> But I'm not sure if this was your question
[14:04] <bzoltan> efes:  are you on 14.04, 14.10 or on 15.04?
[14:04] <bzoltan> efes:  try the devel-proposed
[14:04] <efes> bzoltan: vivid
[14:04] <efes> okay
[14:04] <bzoltan> efes:  make sure that the emulator is properly set up .. enough disk space, enough memory. generic stuff
[14:05] <bzoltan> efes:  the emulator should start, no question about that :)
[14:05] <efes> It is. As it would be my first run, I am keeping all my environment vanilla ;P
[14:07] <efes> bzoltan: This should be done with ubuntu-emulator create, not the GUI app. Am i right?
[14:10] <efes> btw: does anyone know if there is equivalent for .nomedia file on Ubuntu, so that some directories are not scanned agains media data?
[16:58] <wardster> just trying to depoloy app to ubuntu touch, it runs fine but when deploying i get bad port<EMAIL_ADDRESS>[16:58] <wardster> i can see another 1 is in the line it should be<EMAIL_ADDRESS>[16:58] <wardster> were do i change the port to deploy to
[17:28] <Lenny> hey guys
[17:29] <Lenny> i`m very new with programming in general but i need some info
[17:29] <Lenny> is it possible to make games fot ubuntu /desktop and oublish them in the nsoftware center?
[17:37] <Lenny> anyone here?;)
[20:52] <efes> Guys, why there are two options for Ubuntu phone projects? One is cmake and second is qmake. Isn't there any suggested tool?
[22:24] <nik90> efes: What do you mean by suggested tool? They are just providing different project types giving developers the freedom to choose what they are comfortable with
[23:10] <efes> nik90: Fair enough :)
[23:11] <efes> BTW: does anyone know if there is something equvalent to .nomedia file on Android, so that media scanner ignores that given directory ?