[07:57] <ppisati> moin
[09:24]  * apw struggles on with pants internet
[09:24]  * apw struggles on with pants internet
[09:25]  * smb struggles with pant sleepiness
[09:26] <RAOF> Better than pantsless internet!
[09:27] <smb> RAOF, As long as I don't have to see that. :-)
[09:28] <cking> smb 96433f6ee49032d7a8bda76de2b05cfde2914354
[09:40]  * cking offers apw some of his spare internet connection capacity
[09:40] <apw> RAOF, i would settle for using it pantless if it went faster
[09:50] <ppisati> brb
[10:26]  * henrix reboots
[10:41] <jpds> Hey, can someone tell me if linux-image-lts-quantal / so stops being updated for precise after the next LTS is released?
[10:43] <apw> jpds, i believe that is the plan, people there will be updated to the TT kernel on PP and can stay there
[10:43] <jpds> apw: So there'll be a linux-image-lts-t kernel for precise?
[10:44] <apw> jpds, that is my understanding indeed, that we offer an 14.04 kernel as the hwe kernel on 12.04, and the other lts kernels will roll to that one
[10:45] <jpds> apw: What about people on precise, that want to enable hardware that's enabled... after T?
[10:57] <apw> jpds, they need to be on T
[12:14] <BenC> rtg, apw: You're going to want commit 829a337c48b835c322e625e390b0bb07769e913b from my ppc tree
[12:14] <BenC> UBUNTU: SAUCE: 8250: Wrap ACPI calls with ifdefs for non-ACPI systems
[12:15] <BenC> All the commits you cherry picked trashed that driver for anything non-x86
[12:31] <BenC> infinity: Fixed linux-ppc is waiting to build
[12:48] <rtg> BenC, I had some trouble getting that to build on armhf (so I turned off 8250 for armhf IIRC). Have you sent that patch upstream yet ?
[12:48] <BenC> rtg: No, I'm hoping the person that keeps cherry picking for stable kernels will do it for me eventually :)
[12:49] <rtg> I guess it fell off my todo list.
[13:05] <rtg> BenC, see 053fac36b1d9f76adde96a2f731965aaab3c632b in Linus repo. I'll see about getting that fixed in Raring
[13:13]  * henrix -> lunch
[13:37] <apw> rtg, thanks
[13:37] <rtg> apw, uh, for what ?
[13:38] <apw> handling BenC's issue
[13:38] <rtg> ah, no problem
[13:38] <BenC> rtg: that fix does it…I'll disappear my commit from ppc branch next time I sync to ubuntu/master
[13:38] <rtg> build testing armhf right now
[14:01] <apw> rtg, just pushed a bit more fixing for the linaro -> nexus7 rename
[14:01] <rtg> apw, oh, did I push that without testing ? I got distracted I think before it was finished
[14:02] <tjaalton> hum, ideas why i915.ko built from a dkms package is not loaded on haswell, but i915_hsw.ko
[14:02] <apw> rtg no i think what you pushed would build fine, it is reconfiguration and the like which needed more tweaks
[14:02] <rtg> apw, cool, thanks.
[14:02] <rtg> tjaalton, PCI IDs ?
[14:02] <apw> tjaalton, well i think it would load both and whichever binds get sit ?
[14:02] <apw> gets the device
[14:03] <tjaalton> hmm right
[14:03] <apw> tjaalton, also where is i915_hsw.ko, is that in updates/ or just in the normal place
[14:03] <tjaalton> normal place
[14:03] <apw> and the dkms where is that, updates ?
[14:03] <tjaalton> yeah I see in dmesg that it's probably trying to load both
[14:03] <tjaalton> yep
[14:04] <apw> as i think i expect updates to be loaded first, but probe is async i think
[14:04] <tjaalton> lspci shows i915 being used, but lsmod shows i915_hsw
[14:04] <tjaalton> so I think lspci lies
[14:04] <apw> so ... perhaps the dkms package should include an /etc/modprobe.d/stop-haswell.conf which blacklists i915_hsw.ko
[14:04] <tjaalton> yep
[14:05] <tjaalton> probably the cleanest way out of this
[14:05] <apw> but that is a bit pants
[14:05] <tjaalton> :)
[14:06] <tjaalton> rtg: the dkms version supports all, _hsw only haswell. so the dkms package works for !HSW. anyway, blacklist it is then
[14:07] <rtg> tjaalton, ack. Is this going to be your preferred solution for Haswell platforms ?
[14:08] <tjaalton> rtg: until i915_hsw is rebased, but the dkms is needed right now
[14:09] <rtg> tjaalton, so you're still gonna send a pull request for quantal eventually ?
[14:09] <tjaalton> yeah I hope so :)
[14:09] <rtg> k
[14:09] <tjaalton> been fighting fires so didn't get to it yet
[14:11] <rtg> tjaalton, my kid fights fires in the summer. it pays pretty well.
[14:12] <tjaalton> hehe
[14:37] <seiflotfy> guys
[14:38] <seiflotfy> centrino 6300 on raring has a big issue with disconnecting then becoming unavailable
[14:39]  * ogasawara back in 20
[14:48] <jsalisbury> bjf, fyi, bug bots are broken again on cranberry due to an upgrade :-/
[14:48] <bjf> jsalisbury, that's special
[15:12] <ogra_> ppisati, so the plan is to leave the panda desktops as is and dont touch thzem at all
[15:30] <ppisati> ogra_: then i'll sync up R/omap4 wrt to Q/omap4
[15:30] <ppisati> rtg: ^
[15:30] <rtg> ppisati, ack
[15:30] <ogra_> yep
[15:30] <ogra_> and then let it rot :)
[15:31] <rtg> ppisati, ogra_: if omap4 is now only for the builders, then why bother with an omap4 in Raring ?
[15:33] <ogra_> rtg, we want the community to still have builder options ... and (worse) still want to have them for dogfooding desktop stuff on arm
[15:33] <ogra_> i would have gone with server images from mainline kernels ... 
[15:33] <rtg> ogra_, can we still do that with the device tree kernel in raring ? I'd still like to rename it to something more generic.
[15:34] <ppisati> ogra_: +1
[15:34] <ppisati> rtg: doing it now
[15:34] <ppisati> rtg: s/omap/multiarm/g
[15:34] <ogra_> rtg, i dont care what you guys do as long as pvr still works for desktop 
[15:35] <ogra_> well, s/i/they/ (whoever) :)
[15:42] <rtg> ogra_, can you find the bit of build magic for the N4 kernel ? there has to be a bit more to it then just using arch/arm/configs/mako_defconfig
[15:43] <ogra_> i have never built any official phablet image ... only ported to my own devices and they definitely use a cm_*_defconfig 
[15:43] <ogra_> but i dont see a cm_mako_defconfig in the tree
[15:44] <rtg> cm_x2xx_defconfig  cm_x300_defconfig
[15:44] <ogra_> yep i see them
[15:45] <ogra_> kernel/lge/mako/AndroidKernel.mk ...
[15:45] <rtg> ogra_, looking at the git repo implies that mako_defconfig is in use 'cause that where some config options have been changed for the phablet image
[15:47] <ogra_> did you try running a fresh repo sync ?
[15:49]  * ogra_ doesnt really see where KERNEL_DEFCONFIG gets defined
[15:51] <ogra_> aha device/lge/mako/BoardConfig.mk
[15:51] <ogra_> yeah its mako_defconfig, you are right
[15:53] <ogra_> rtg, so i suspect you have to mimic whatever kernel/lge/mako/AndroidKernel.mk does to get a proper config 
[15:54] <ogra_> there seems to be a bunch of perl touching it 
[15:55] <rtg> ogra_, that lge directory does not exist in git://phablet.ubuntu.com/CyanogenMod/lge-kernel-mako.git
[15:58] <ogra_> weird, must be something repo does merge then
[15:59] <ogra_> likely from CyanogenMod/android_device_lge_mako
[15:59] <ogra_> thats whats defined in the top level manifest.xml here 
[16:00] <ogra_> http://paste.ubuntu.com/5631532/
[16:00] <ogra_> thats the AndroidKernel.mk in my tree
[16:01] <rtg> ogra_, cool, thanks
[16:01] <ogra_> line 14 and 15 look like they touch it 
[17:13] <rtg> apw, git://kernel.ubuntu.com/ubuntu/ubuntu-nexus4.git - can you give me a hand and tell me why  config-check wants to run debian.master/config/enforce ? The N7 script is identical, yet I don't have that failure.
[17:16] <rtg> apw, oh, well actually now I _do_ have the same failure. its part of your patch 'UBUNTU: [packaging] Rename from linaro to nexus7 -- part 2'
[17:29]  * rtg -> lunch
[17:31] <ppisati> rtg: could you refrain from touching R/master-next abi today?
[17:34]  * ppisati -> workout
[17:34] <ppisati> later
[18:02] <cking> bah, ESTA and visas. what a pain
[18:03] <ogra_> and visas ?
[18:03] <ogra_> do you need both in the UK ?
[18:11] <rtg> ppisati, why just the abi ?
[18:57]  * henrix -> EOD
[20:06]  * rtg -> EOD
[20:35] <jbaron> q: i'm trying to build a kernel out of the git tree, and have noticed that a number of the firmware files are dropped - 
[20:36] <jbaron> is there an easy way to figure out what I need to pull in from linux-firmware?