[01:56] <_bjf>  
[07:52] <apw> Sarvatt, ok that fixed mesa automatically switched back to 1.4 just fine.  this highlights that unity dash is now using something whcih isn't there in 1.4 because the color is still wrong
[07:55] <apw> Sarvatt, oh dear, and X just dumped
[07:55] <smb> Sounds like joy
[08:01] <apw> Sarvatt, https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1233540
[08:17] <apw> Sarvatt, ok confirmed that this is a hard crash caused when chromium opens glx, so navigating to maps.google.com is instantly fatal for the x server
[10:49] <Kaloz> apw: hey. do you want me to do that bug report from the custom kernel with working audio or from the ubuntu kernel?
[10:49] <apw> Kaloz, i suspect apport in its infinite wisdom will not let you from the custom one
[10:50]  * apw adds this to his list of HATES for apple
[10:50] <Kaloz> apw: as it's just a rebuild of 3.11.0-7 it would think it is ;)
[10:50] <apw> just get your shit right poople
[10:50] <apw> Kaloz, don't be money on it not catching you out
[10:50] <apw> s/be/bet/
[10:50] <Kaloz> apw: actually that codec lacked support upstream and the acpi bug could affect other boards as well,as it's not apple specific ;)
[10:50] <apw> Kaloz, i don't care which you file it against for sure
[10:51] <apw> Kaloz, it really is ....
[10:51] <apw> +[CS4208_MBA6] = {
[10:51] <apw> that isn't a generic name that is a MacBookAir specific quirk
[10:51] <apw> bloody apple
[10:51] <Kaloz> apw: that's the second one, which is apple specific, but the other one is simply a blind shot for cs4208
[10:52] <Kaloz> and anyways, as I've told before, this was the only haswell based notebook I could pick up
[10:52] <apw> oh i don't hate you for it, i hate apple
[10:53] <Kaloz> shame on lenovo for being so debianistickly sta^H^H^Houtdated
[10:56] <apw> Kaloz, i am pretty sure a lot of people round here have lenovo's
[11:00] <apw> Kaloz, anyhow let me know the bug number so i can get the right people thinking about it
[11:01] <apw> ppisati, about ?  i am getting log spam on my omap4 with
[11:01] <apw> ppisati, -generic installed:
[11:01] <apw> Oct  1 05:55:31 elloco kernel: [43481.748138] omap_i2c 48070000.i2c: timeout waiting for bus ready
[11:01] <apw> Oct  1 05:55:31 elloco kernel: [43481.748168] twl6040 0-004b: Failed to read IRQ status: -110
[11:03] <apw> seems to be happening since reboot, and i didn't see it on a previous boot
[11:03] <apw> oh this was a warm boot, previos likely cold
[11:03]  * apw wonders if that is his non-working un-used wifi whining
[11:56] <Kaloz> apw: bug #1233623
[12:15] <apw> Kaloz, thanks
[12:20] <Kaloz> apw: nah, thanks for taking the time
[12:34] <apw> sforshee, on your air could you see what code you are using, i am told head -1 /proc/asound/card*/codec*
[12:36] <sforshee> apw: "Cirrus Logic CS4206" and "Intel PantherPoint HDMI" are what I get
[12:36] <apw> sforshee, perfect the top one is the one i want to make sure we arn't screwing up
[12:47] <apw> Kaloz, sforshee, ChickenCutlass, i have applied those macbookair fixes against the latest saucy tip, and built some test kernels
[12:47] <apw> could you test on the kit you have and report back please:
[12:47] <apw> http://people.canonical.com/~apw/lp1233623-saucy/
[12:48] <apw> sforshee, for you i am interested it keeps working ok rather than changes anything
[12:49] <ChickenCutlass> apw, will do
[12:58] <ChickenCutlass> apw, works great.  Headphones also working as expected.
[12:58] <ChickenCutlass> apw, mutes speakers
[13:04] <apw> ChickenCutlass, i assume thats mutes speakers when you want and expect :)
[13:04] <apw> if you could report any testing back in the bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1233623 as well thanks
[13:04] <ChickenCutlass> apw, yes, everything (sound wise) working quite nicely 
[13:04] <ChickenCutlass> sure
[13:05] <apw> ok good thanks, if it doesn't regress the old ones such as seths then we are good
[13:05] <ChickenCutlass> fantastic
[13:06]  * henrix -> lunch
[13:08] <amitk> apw: how fast can you compile all kernel flavours for a new kernel upload? And how many flavours is this today? (I'm trying to estimate what HW I need to order for CI loops)
[13:08] <caribou> apw: FYI, I added my kernel dump analysis to bug: #1233175
[13:08] <caribou> apw: the mempolicy bug
[13:09] <Kaloz> ChickenCutlass: what doesn't work for you, yet?
[13:09] <ChickenCutlass> Kaloz, 2 things left
[13:09] <ChickenCutlass> Kaloz, the camera, no longer a USB ucvvideo device
[13:09] <ChickenCutlass> Kaloz, and screen brightness on resume
[13:10] <ChickenCutlass> Kaloz, screen brightness actually works on resume but only 2 levels -- full brightness and off
[13:11] <Kaloz> ChickenCutlass: well, for the camera we're pretty much out of luck ;)
[13:11] <ChickenCutlass> Kaloz, yeah figured
[13:11] <ChickenCutlass> Kaloz, oh -- one more thing.  I need to pass noncq for libata at boot
[13:11] <Kaloz> ChickenCutlass: does the audio work fro you on resume? also, I still find ncq errors if give it massive load
[13:11] <ChickenCutlass> Kaloz, just need to add a quirk
[13:13] <Kaloz> ChickenCutlass: are you booting in legacy or efi mode?
[13:13] <ChickenCutlass> Kaloz, efi
[13:13] <Kaloz> with efi the ncq errors only show up for me after random time, but boot always succeeds even without noncq
[13:13] <ChickenCutlass> Kaloz, so you should add to your kernel command line libata.force=noncq
[13:13] <ChickenCutlass> Kaloz, makes things muich better
[13:16] <Kaloz> ChickenCutlass: did, just saying the problem isn't as bad as in legacy mode
[13:17] <ChickenCutlass> ok
[13:18] <apw> amitk, today we make one, and it takes about 20 mins to build on a big ass box, about 1 hour on the buildds
[13:20] <apw> amitk, that of course is x86, and we have to maek one for each x86, arm is a differnet story
[13:32] <sforshee> apw: what all do I need to check? Internal speakers, volume, and internal mic all seem to be fine.
[13:33] <apw> sforshee, yeah "did we break your sound" is what i am trying to acertain
[13:34] <sforshee> apw: definitely not broken
[13:36] <apw> Kaloz, worked for you ok ?
[13:38] <rtg> apw, pushed some MB Air audio patches, etc
[13:39] <apw> rtg, heh ... then i won't push them then, now that seth has tested them for older kit
[13:40] <rtg> apw, hmm, the code looked like it really couldn't regress. did I miss something ?
[13:40] <apw> rtg, i am handling the d-i changes from cjwatson
[13:40] <rtg> apw, ack
[13:40] <apw> rtg, heh no, just treading on each others toes :)
[13:41] <rtg> apw, ok, I'll go find someone elses toes to stomp on
[13:51] <rtg> cking, so, you're thinking CONFIG_NO_HZ_IDLE=y for all arches on saucy ?
[13:51] <cking> rtg indeed
[13:51] <rtg> cking, ack
[13:52] <rtg> cking, I will use my god like commit powers and slam in a config change
[13:52] <cking> rtg, many thanks
[14:16] <cking> no more saucy patches from me until next upload :-)
[14:32] <Kaloz> apw: yup, works :)
[14:33] <Kaloz> apw: just thought I'll skip the "mee too" part
[14:34] <apw> Kaloz, heh always good to have positive testing recorded in the bug
[14:34] <apw> Kaloz, patches are applied for the next upload
[14:35] <petn-randall> Hi, while setting up monitoring checks (specifically check_running_kernels) I noticed that /boot/vmlinuz* have 0600 permissions, while on Debian it's 0644. Is there a rationale behind this? I didn't find any info on this yet.
[14:43] <apw> petn-randall, i have the feeling it was part of making it harder to 
[14:44] <apw> get the symbols when running in an exploit, not sure it has a heap of value, but i think it was related to that
[14:44] <apw> kees might remember the exact reasoning
[15:18] <jsalisbury> **
[15:18] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:18] <jsalisbury> **
[16:55] <jsalisbury> ##
[16:55] <jsalisbury> ## Kernel team meeting in 5 minutes
[16:55] <jsalisbury> ##
[17:01] <jsalisbury> ##
[17:01] <jsalisbury> ## Meeting starting now
[17:01] <jsalisbury> ##
[17:05]  * ppisati -> EOD
[18:11] <Kaloz> apw: yay, thanks 
[18:22] <rtg> apw, pushed v3.11.3 rebase
[18:22] <apw> rtg, ack, pushed final hyper-v fix as well
[18:23] <rtg> apw: 'Drivers: hv: balloon: Initialize the transaction ID just before sending' ?
[18:23] <apw> rtg, oh you pushed it off
[18:23] <rtg> damn, I just fetched
[18:23] <apw> rtg, will fix
[18:23] <rtg> wow, that was only about a 30 second window
[18:24] <apw> rtg, eheh yeah, you can tell fromt eh messages that something is lost, getting it back is hard if you don't know who
[18:25] <apw> rtg, pushed
[18:25] <rtg> apw, got it
[18:55] <cheater__> i have downloaded a kernel for ubuntu and now i need the source for it. could someone help me figure this out? the kernel is here: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.11.2-saucy/ and there are some patches in there but there is no source. how do i get the source?
[18:57] <cheater__> i am trying to get the logitech t651 bluetooth touchpad drivers to work, and possibly contribute to them later on so that they can be put in the mainline at some point
[18:59] <baordog_> https://wiki.ubuntu.com/Kernel/SourceCode duuuude
[18:59] <apw> cheater__, the patches there are against the commit listed in COMMIT
[18:59] <baordog_> http://archive.ubuntu.com/ also this
[18:59] <apw> cheater__, so in that case you would need to get a linus' upstream tree with the v3.11.2 tag in it
[19:00] <apw> check that out, and apply the patches as listed to get the source we built
[19:00] <cheater__> apw, hmm, ok
[19:00] <cheater__> now i'm confused about this doc for building the kernel module
[19:00] <cheater__> https://bbs.archlinux.org/viewtopic.php?id=166924&p=2
[19:01] <cheater__> this is what i am looking at. basically he checks out linux, then adds his clone as remote, and switches to a branch he got from that.
[19:01] <cheater__> then he builds it like this: make -C /usr/src/linux-`uname -r` M=$PWD/drivers/hid modules -j8 CONFIG_HID_LOGITECH_HIDPP=m CONFIG_HID_LOGITECH_WTP=m
[19:01] <apw> that is pretty arch centric
[19:01] <cheater__> now i'm a bit confused. isn't /usr/src/linux-`uname -r` going to be the kernel source? isn't that exactly the same source as in the git clone?
[19:02] <cheater__> apw, OK. what issues do you see there?
[19:02] <apw> cheater__, no you don't need the whole source typically you use the 'headers' pakcages to build external modules
[19:02] <cheater__> right, i have the headers
[19:03] <cheater__> so are you saying i should just use /usr/src/linux-headers-`uname -r` ?
[19:03] <apw> so /usr/src/linux-headers-`uname -r` is your 'source' for building modules
[19:03] <apw> yep
[19:03] <apw> at least in theory
[19:03] <cheater__> let's try and see
[19:03] <apw> good luck
[19:03] <cheater__> you said the instructions were "arch centric", what other issues did you see?
[19:04] <apw> just that they are arch speciific filenames wise, beyond that not read any further
[19:04]  * apw wanders off to get food
[19:05] <cheater__> ok, gotcha. thanks!
[19:40] <kees> petn-randall, apw: right, it is to discourage automated bot-style attacks that attempt to get kernel addresses from the files on disk.
[19:41] <apw> kees, i was close :)
[19:41] <kees> yup
[20:05] <apw> rtg, hey we seem to have a double ABI bump... didn't you make startnewrelease do an abi bump, then you've added a second
[20:05] <rtg> apw, we definitely did. should be OK though
[20:06] <apw> rtg, yeah doesn't matter, but for next time
[20:06] <rtg> apw, that was just me screwing the pooch
[20:06] <apw> had me scrambling to find -10 :)
[20:07] <rtg> apw, yeah, I added the ABI bumper patch (then promptly forgot)  'cause its gonna be bjf's kernel here pretty soon.
[20:07] <apw> heh yeah
[21:09]  * rtg -> EOD
[21:18] <TonnyNerd> I am using ubuntu 12.04, can anyone tell me if AUFS is being supported on newer releases?
[21:19] <TonnyNerd> I've read the kernel-delta stuffs, but I didn't quite got if it was in or out
[21:32] <cheater_1> hi guys
[21:32] <cheater_1> apw: thanks for your help, i have successfully built the module.
[22:02] <TonnyNerd> I am using ubuntu 12.04, can anyone tell me if AUFS is being supported on newer releases?
[22:29] <cheater_1>  
[22:29] <cheater_1> sorry, typo
[22:41] <bjf> TonnyNerd, yes, it's supported
[22:51] <TonnyNerd> bjf: so, it was just in 12.04? Or there are plans to drop it for good in the future?
[22:52] <bjf> TonnyNerd, you asked if it is supported in releases newer than 12.04 and i said yes it is.
[22:55] <TonnyNerd> bjf: What I meant is, I read that it maybe would be dropped in favor of overlayfs, is it still going to happen?
[23:07] <bjf> TonnyNerd, i believe we are using overlayfs but we still include aufs in the kernel
[23:10] <TonnyNerd> bjf: cool. I have this EC2 instance with 12.04, kernel 3.2.0-40, and aufs just doesn't work. Is it a known problem with the kernel/ubuntu version, or did I missed something?
[23:11] <bjf> TonnyNerd, i'm not aware of that issue. you should file a bug.
[23:12] <TonnyNerd> bjf: can you point me to the right bugtrack?
[23:12] <bjf> TonnyNerd, launchpad.net
[23:15] <TonnyNerd> bjf: this one: https://bugs.launchpad.net/ubuntu? Sorry for the dummy questions, I've never filled a bug for launchpad before, want to do it as right as possible
[23:15] <bjf> TonnyNerd, https://bugs.launchpad.net/ubuntu/+source/linux/+filebug
[23:16] <bjf> TonnyNerd, if you can it's actually best to run "ubuntu-bug linux" from your ec2 instance 
[23:16] <bjf> TonnyNerd, that will collect additional information. however, i've never tried it from an ec2 instance
[23:17] <TonnyNerd> bjf: I will give it a try, as soon as my computer stops misbehaving (too much chrome tabs)
[23:34] <TonnyNerd> bjf: did it: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1233903
[23:34] <ubot2> Launchpad bug 1233903 in linux (Ubuntu) "aufs doesn't work, even with aufs-tools installed" [Undecided,New]
[23:34] <bjf> ack
[23:34] <TonnyNerd> in the meantime, I guess I should try 13.04? I am hesitant because it's not a LTS version
[23:44] <TonnyNerd> I just created a new 13.04 EC2 instance, and aufs still doesn't work. Maybe it's an issue with amazon's amis
[23:45] <TonnyNerd> I am running a apt-get upgrade right now, gonna test again after that
[23:52] <TonnyNerd> bjf: It doesn't work on 13.04 either, and a post on amazon's forums seems to suggest it's a known thing (I should've looked there before), should I close that bug myself? (I am not sure how the process works, sorry)