[07:21] <ppisati> moin
[07:30] <smb> morning
[07:49] <ppisati> compiz is sucking ~29% of my cpu time
[07:49] <ppisati> and i'm not doing anything
[07:50] <infinity> ppisati: Try doing even less.
[07:51]  * infinity hands ppisati a breakfast mimosa.
[07:52] <ppisati> with just an open terminal and top running in it, it goes down to ~15%
[07:56] <infinity> ppisati: Is mx53 included in the multiplatform kernel, or just mx6?
[07:56] <infinity> ppisati: (And, if not, can it be, or does upstream only support mx6 for multiplatform?)
[08:04] <ppisati> infinity: it's not supported because no one has the hw to test it, but everything is there, just a config away
[08:05] <infinity> ppisati: I have the hardware to test it, and some other people who'd like me to enable it in the installer, hence the question. ;)
[08:06] <infinity> ppisati: If it's as simple as flipping a CONFIG_ or two, please do, and I'll test when I get a chance.
[08:06]  * apw yawns
[08:06] <infinity> apw: Morning, sunshine.
[08:06] <apw> i have morning and sunshine indeed
[08:07] <apw> i may even get to sit outside today, and find out if my interwebs work there
[08:07] <smb> You mean you actually have this sunshine thing
[09:01]  * ppisati reboots
[09:48] <ppisati> infinity: http://people.canonical.com/~ppisati/linux-image-3.8.0-20-generic_3.8.0-20.31~imx53_armhf.deb
[09:48] <ppisati> infinity: and tell me if  it workr
[09:48] <ppisati> *worked
[09:50] <infinity> ppisati: I'll try to get to it this week.  Need to hook a hard drive up to my mx53 first (the last one died).
[09:52] <ppisati> infinity: ack
[09:53]  * ppisati goes out for an early lunch
[10:40] <gema_> cking: ping
[10:41] <cking> gema_, pong
[10:41] <gema_> cking: we are observing some changes on the test cases
[10:41] <gema_> cking: power for amd64 / i386
[10:41] <gema_> cking: things seem to have improved in most of them except the idle one
[10:41] <gema_> cking: I wondered if you have an explanation or theory for that
[10:42] <gema_> cking: eom
[10:42] <cking> gema_, I need to study the data first
[10:42] <gema_> cking: ack: http://reports.qa.ubuntu.com/power/hardware/arch/i386/
[10:43] <gema_> cking:  I will ask the lab guys if they've made any changes later today
[10:44] <cking> gema_, surely its because 3.9 is being used now
[10:44] <gema_> cking: makes sense
[10:46] <cking> gema_, it's hard to tell - it is not trivial to easily spot which packages are different between runs
[10:47] <gema_> cking: that's a change in utah we discussed and we should implement, list of packages and versions installed on a particular system
[10:47] <gema_> cking: making a note
[10:47] <cking> would me most useful, otherwise it takes a lot of effort to figure our which image was used and which packages were installed
[10:47] <gema_> cking: ack
[11:26] <smb> :q
[12:34] <apw> henrix, yo
[13:13]  * ppisati notes that the R update made skype disappear from the top bar (task bar? indicator bar? $whatever)
[14:43] <apw> ppisati, from the indicator area (top right)
[14:47] <ppisati> apw: yes, the systray bar
[14:48] <apw> ppisati, it is there for me, with an up to date raring
[14:48] <ppisati> apw: same on my laptop
[14:49] <ppisati> apw: but not on my desktop...
[14:49] <apw> odd indeed
[17:04] <user_> im having major wireless connection drops and low power issues. AR9485 ath9k - 3.2.6kernal
[17:27] <bjf> apw, is this you? https://launchpad.net/~kernel-ppa/+archive/pre-proposed
[17:29] <apw> bjf, i upload things there indeed.
[17:29] <bjf> apw, is that the master-next branch from our ubuntu-<series> trees?
[17:35] <apw> bjf, yeah should be
[17:36] <bjf> apw, so, can we get raring kernels now?
[17:37] <apw> oh
[17:37] <apw> hmmm
[17:37] <apw> bjf, looking
[17:37] <bjf> :-)
[17:39] <apw> bjf, L P Q R are the only ones we have left right ?
[17:39] <bjf> apw, yes
[17:52] <apw> bjf, ok ... gomeisa is on the job
[17:52] <bjf> apw, thanks
[17:52]  * apw adds a todo item to put together a 'release checklist' for all this shit
[17:56] <apw> bjf, ok they are in and should remain in for the forseeable
[17:58] <apw> bjf, not that that will build for a few hours yet
[17:58] <bjf> apw, good enough
[17:59] <apw> they build a lot better if they hit at the normal time, 9ish UTC
[18:19] <infinity> zequence: lowlatency is getting behind on SRUs again.
[18:19] <infinity> apw: ^
[18:19] <apw> oh that is my fault
[18:19]  * apw will sort it out now
[18:19] <infinity> apw: And, while we're at it, do we need to have a chat with Ben about linux-ppc SRUs, or shall we JFDI on our end?  Preference?
[18:19] <apw> i guess we ought to mention it to him at least
[18:19] <infinity> BenC: *poke*
[18:19] <apw> :)
[18:20] <BenC> infinity: aye
[18:20] <infinity> BenC: Did you have a plan/commitment/urge regarding linux-ppc SRU/security rebases for raring and beyond?
[18:20]  * BenC hasn't been getting any notifications of needed ppc builds
[18:20] <apw> bjf, are we making bugs for linux-ppc for raring when we spin srus ?
[18:21] <BenC> infinity: anyway I can get something automated so I don't have to remember to keep checking git/launchpad/archive?
[18:21] <infinity> BenC: If bjf's scripts created workflow bugs for you like https://bugs.launchpad.net/kernel-sru-workflow/+bug/1177550 would you use them?
[18:21] <ubot2> Launchpad bug 1177550 in Kernel SRU Workflow "linux-lowlatency: 3.8.0-20.14 -proposed tracker" [Medium,In progress]
[18:21] <BenC> I can sync it today, but in the future...
[18:21] <BenC> Yes, most definitely
[18:22] <infinity> bjf: Can we add linux-ppc to the derivative bug magic for raring+ ?
[18:22] <infinity> BenC: We might want to follow the same workflow lowlatency does (they prepare in their own PPA, and then Andy copies to the kernel PPA), since the kernel PPA is not built against updates, thus guaranteeing a clean build for security.
[18:23] <infinity> BenC: (As opposed to you uploading directly to -proposed, which does build against updates)
[18:23] <infinity> s/Andy copies/Andy does a source-only copy/
[18:23] <apw> yep else we canot use them into -security
[18:24] <BenC> Is there some better explanation of this workflow…do I even need to interact with it, or is the automation able to take my git tree and handle it from there?
[18:24] <infinity> We might need to explain the testing tasks, and how we plan to use them.
[18:24] <infinity> We'll fiddle with that the first time we go through it. ;)
[18:25] <BenC> Ok, if who ever handles low latency could point me at some bullet list of how they handle this work flow, I'll be more than happy to join in…anything that makes it easier between me and your guys work
[18:25] <infinity> But the initial "upload" bit would be you prepping it either in git or git and a PPA upload, and then setting "upload-to-ppa" to "Confirmed".
[18:25] <BenC> Or walk me through it once :)
[18:26] <infinity> (And a comment pointing at where the rebase lives, PPA or git URL)
[18:26] <infinity> But the testing bit, we'll just walk you through how to use the tasks once we have a tracking bug for you on the next cycle.
[18:26] <infinity> Unless bjf wants to make one for you now.
[18:26] <infinity> But coaxing the bot to make just one derivative bug is hard, I believe. :P
[18:27] <bjf> BenC, maybe i'm wrong but i thought we were doing that and you asked us to disable it, i see a comment that the tracking bugs for linux-ppc were not being used
[18:27] <infinity> BenC: In a nutshell, though, the way we've been doing lowlatency is to mark Cert and Security invalid (the former being Canonical Cert testing, the latter is inherited from the master branch)
[18:28] <infinity> BenC: And then for Verification-testing, if it has no changes beyond the rebase, just mark it done, if it has its own changes and bugs, verify those first.
[18:28] <BenC> bjf: I don't believe I was ever asked…and if I was, I don't believe I understood what was being asked and why :)
[18:28] <infinity> BenC: And for regression-testing, some boot-testing on hardware is nice. :P
[18:28] <infinity> BenC: But we'll walk through it larer.
[18:28] <infinity> bjf: I think it was disabled when you started using tracking bugs for *development* releases.
[18:28] <infinity> bjf: For SRUs, though, they're monumentally helpful.
[18:29] <infinity> BenC: Though, that said, some sort of linux-ppc 3.9 for saucy would be neat some day.  No pressure. ;)
[18:29] <BenC> I'll get that done this week too :)
[18:30] <infinity> bjf: If you can do a one-off linux-ppc tracking bug for the current cycle, that would be cool, and I can walk Ben through vaguely what we do for lowlatency.
[18:31] <infinity> bjf: If that's serious hassly to coax the bot into doing that properly with the right inheritance and such, just turn it on for the next cycle, please. :)
[18:31] <bjf> infinity, BenC the script is updated
[18:31] <BenC> Thanks
[18:31] <infinity> s/serious hassly/a serious hassle/
[18:31] <infinity> No idea what my fingers were doing when I typed that.
[18:33] <bjf> infinity, BenC looking at creating a tracking bug by hand .. will let you know when ready
[18:34] <infinity> bjf: Will it have the proper attachment/ancestry with the master bug (so security/promote tasks follow, etc), or will it be "orphaned"?
[18:34] <infinity> bjf: If the latter, possibly not worth the hassle, and we can just wait for the next automagic one.
[18:35] <bjf> infinity, orphaned
[18:35] <infinity> Yeah, that's less cool for teaching him how it all works, then.
[18:35] <infinity> We can probably just by-hand this set entirely and skip the bug.
[18:35] <infinity> Less effort for you this way, too. :P
[18:37] <infinity> BenC: In fact, given that there have been no drastic changes to toolchain or other rdeps in raring yet, I'm perfectly fine with you just doing a rebase and throwing it directly at the raring(-proposed) queue for this one.
[18:37] <infinity> BenC: And we'll work on doing it "the SRU kernel way(tm)" for the next cycle.
[18:38] <BenC> infinity: Ok, so treat it just like during development cycle for this one?
[18:38] <infinity> BenC: Yeahp.
[18:38] <BenC> Will do