[08:14] <tjaalton> hmh, power consumption is up on quantal, my t420s takes 15W when it used to take only 7-8W on precise
[08:14] <tjaalton> while idle
[08:16] <hyperair> that's a huge difference.
[08:16] <tjaalton> yeah
[08:17] <tjaalton> double-checked that it's not using optimus :)
[08:17] <hyperair> hm
[08:17] <caribou> guys, I have a git bisect question for you
[08:17]  * hyperair has noticed power consumption increases over the years, but couldn't really attribute it to power consumption regressions or battery degradation.
[08:18] <caribou> I have an issue where it works on older kernel (3.2.0-29.46) and fails in newer kernel (3.2.0-31.50)
[08:18] <tjaalton> powertop doesn't show the acpi estimate anymore, so I'm looking at the gnome power stats
[08:18] <hyperair> tjaalton: acpi can estimate? i thought that was purely a powertop calculation.
[08:18] <tjaalton> huh, now it shows ~9W
[08:19] <caribou> which git bisect bad/good version should I use ?
[08:19] <caribou> git bisect start Ubuntu-3.2.0-31.50 Ubuntu-3.2.0-29.46 ???
[08:19] <hyperair> caribou: bisect was meant to find regressions, so bad is always after good.
[08:20] <hyperair> if you're trying to find a commit to cherrypick, you have to manually invert that logic yourself, or git bisect gets confused.
[08:20] <caribou> hyperair: so since I'm after a regression, the command above would be correct then ?
[08:20] <hyperair> caribou: yep
[08:21] <caribou> hyperair: great, I wasn't too sure and I don't want to start bisecting the wrong way !
[08:21] <caribou> hyperair: thanks a lot
[08:21] <hyperair> caribou: np. and yeah i know how terrifying kernel bisects are :-)
[08:21]  * hyperair had to run a 20-step bisect once
[08:21] <hyperair> that was horrifying
[08:22] <caribou> hyperair: well, this one is ~8 steps. 
[08:22] <hyperair> ah have fun
[08:22] <caribou> hyperair: an issue with iscsi hanging the kernel with latest Precise kernel
[08:23] <caribou> hyperair: https://bugs.launchpad.net/bugs/1056746
[08:23] <ubot2> Launchpad bug 1056746 in linux "kernel panic on iscsi target disconnect" [High,Incomplete]
[08:23] <hyperair> hmmmm maybe it wasn't 20 steps.. 2^20 seems to be on the order of a million commits or so
[08:48] <tjaalton> ok, the power consumption is back to normal levels, dunno what was wrong there for a (long) while
[08:52] <hyperair> hmm.
[08:52] <hyperair> weird.
[08:53] <cking> tjaalton, how are you measuring power consumption?
[08:54] <cking> try measuring using "powerstat"
[08:54] <tjaalton> cking: oh, didn't know of that tool
[08:55] <tjaalton> just used gnome power applet (?)
[08:55] <cking> tjaalton, its one I hacked up when doing ACPI battery calibration tests last cycle
[08:59] <tjaalton> ah, nice
[08:59] <tjaalton> ~7.8W with bluetooth turned off
[09:04] <cking> tjaalton, that sounds better
[09:05] <tjaalton> yes :)
[10:39] <psivaa> apw ping
[10:40] <psivaa> apw: re bug 1066883, i have tried with 3.5.4 and it fails with that too with plymouth-splash enabled
[10:40] <ubot2> Launchpad bug 1066883 in linux "Fatal server error: Can not run in framebuffer mode on reboot" [High,Confirmed] https://launchpad.net/bugs/1066883
[10:50] <apw> psivaa, when you say "without plymouth-splash" is that just removing splash from the command line ?
[10:51] <psivaa> apw: i renamed /etc/init/plymouth-splash.conf to /etc/init/plymouth-splash.conf.disabled
[10:52] <apw> psivaa, so did you try removing splash at grub?  did that work also?
[10:52] <psivaa> apw: i did not try removing splash at grub
[10:52] <apw> psivaa, that would be a good test as well
[10:53] <psivaa> apw: ill try that now then
[11:17] <psivaa> apw: i tried with kernel command line disabling of quite splash with 3.5.3 but its failing on that
[11:18]  * henrix -> lunch
[11:24] <smartboyhw> Er when will the 3.7-rc1 mainline build be built?
[13:52] <apw> if smarty was here, i could tell hi that they are building now
[15:08] <habach> Hi, I am too new here and have some silly questions, why I cant see any chatting?
[15:57] <jsalisbury> **
[15:57] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:57] <jsalisbury> **
[16:32] <apw> habach, it is release week so people are busy, but ask and you may even get an answer :)
[16:46] <ppisati> reboot, brb
[17:12] <rtg> apw, dropping the async rootfs patches fixed the 3.7-rc1 boot problem. I pushed the reverts and will reset the tag to a working commit
[17:13] <apw> rtg, ack
[17:27] <ricotz> rtg, hi, thanks for rebasing ubuntu-r :)
[17:27] <rtg> ricotz, looks like its working now
[17:27] <ricotz> is the latest branch suppose to built
[17:27] <ricotz> hmm, i see
[17:28] <rtg> ricotz, master-next is the current working version. the tag is Ubuntu-3.7.0-0.1-rc1
[17:28] <ricotz> i am running into this error "cp: cannot stat `drivers/media/dvb/dvb-core/*.h': No such file or directory"
[17:29] <ricotz> building with http://paste.debian.net/plain/201094
[17:30] <rtg> ricotz, fdr clean;echo "dpkg-buildpackage -B -us -uc 2>&1 |tee log.txt"|schroot -c quantal-amd64
[17:31] <rtg> assuming you have a quantal schroot
[17:31] <ricotz> rtg, i don't ;)
[17:31] <ricotz> but i don't want to build all flavors
[17:32] <rtg> you don't need one, it'll build on precise or quantal
[17:32] <ricotz> just the generic one
[17:32] <rtg> ricotz, there is only one flavour now
[17:32] <ricotz> oh
[17:33]  * rtg -> lunch
[17:33] <ricotz> rtg, thanks
[17:47] <apw> bjf, can we stagger the builds for SRUs, you are eating the distro buildds and it is release week
[17:47] <bjf> apw, henrix ^
[17:48] <bjf> henrix, let's hold off until after the release
[17:48] <henrix> apw: ah, sure. i've uploaded oneiric and lucid only
[17:49] <bjf> apw, can they just be re-queued and have their priority dropped?
[17:49] <apw> henrix, it is best to confirm on #ubuntu-release before dropping things on the queue during release week
[17:50] <apw> bjf, no as the buildds are idle, so they pick up the job regardless
[17:50] <henrix> apw: ack, i'll do that.
[17:50] <apw> bjf, as long as we have only one building at once, we'll likely not get told off
[17:50] <apw> henrix, its just this week thats critical
[17:51] <henrix> apw: sure. i'll hold off any uploads
[17:51] <henrix> apw: and ping the release channel first
[17:51] <apw> cool thanks
[17:51] <bjf> henrix, you can have everything else ready and when the release goes out, upload
[17:52] <henrix> bjf: ack
[17:52] <apw> sounds great
[17:52] <bjf> henrix, this cycle has an extra week in it anyway due to UDS
[17:53] <henrix> bjf: yep, makes sense. so i'll hold all the uploads for now.
[17:54] <henrix> bjf: i was too eager to try my new powers :)
[17:54] <bjf> lol
[17:55] <bjf> henrix, they should only be used for good, not evil
[17:56] <henrix> bjf: heh
[17:59]  * henrix -> EOD
[20:15] <geofft> What's the right way to write a (local) package that includes a kernel module?
[20:57] <hallyn> hey - in which package is the openvswitch kernel module from upstream shipped?
[20:59] <hallyn> seems like it should be in generic..
[21:02] <hallyn> hm, is it built-in?
[21:02] <rtg_> hallyn, might be
[21:02] <hallyn> nope
[21:02] <hallyn> but i can't find the module...
[21:03] <rtg_> hallyn, CONFIG_OPENVSWITCH=m for ubuntu-r
[21:03] <hallyn> and q
[21:03] <rtg_> checking
[21:04] <rtg_> net/openvswitch/
[21:04] <rtg_> hallyn, is that what you're looking for ?
[21:05] <hallyn> rtg_: find /lib/modules/ -name "openvswitch*" gives me nothing
[21:05] <hallyn> (on a fresh quantal instance)
[21:05] <rtg_> hallyn, did you install extras ?
[21:05] <rtg_> linux-image-extras*
[21:05] <hallyn> trying
[21:06] <rtg_> hallyn, you should be using the meta package for -server or -generic
[21:07] <hallyn> rtg_: I'm not installing a kernel, just firing up canonistack instances with latest quantal ami
[21:07] <hallyn> should those be installed by default?
[21:07] <hallyn> assume not if called 'extras' :)
[21:07] <rtg_> hallyn, since that uses the -virtual meta package, linux-image-extra won't be installed
[21:08] <hallyn> rtg_: sudo apt-get install linux-image-extra-virtual worked for me, thanks!
[21:08] <rtg_> hallyn, np
[21:09] <hallyn> i suspect openvswitch-datapath-source's README.debian should mention that.  (but will note that for later)
[21:29]  * rtg -> EOD
[21:47] <arges> sforshee, hi