[00:05] <F41l> man, I'm a bit miffed
[00:06] <F41l> This clovertrail junk :(
[00:06] <F41l> I'd have hoped some enterprising kernel devs would have taken that "challenge accepted" I read about intel saying no linux support on clovertrail and made it work.
[00:51] <BenC> apw: Are you guys just incrementing the ABI during development on master regardless of whether it is needed or not?
=== smb` is now known as smb
=== fmasi_afk is now known as fmasi
=== fmasi is now known as fmasi_afk
[08:11]  * apw yawns
=== e11bits_ is now known as e11bits
=== fmasi_afk is now known as fmasi
=== fmasi is now known as fmasi_afk
[08:48] <infinity> BenC: Did you pick up the debian/control change from apw on that upload too?
[08:48] <infinity> apw: Or did you not push that to github yet?
=== cjwatson_ is now known as cjwatson
=== fmasi_afk is now known as fmasi
[09:07] <cking> apw, http://lwn.net/Articles/365835/
[09:08] <apw> infinity, i didn't have push rights when i tried last
[09:08] <infinity> apw: Oh, weird.  I thought we both did.
=== ohsix_ is now known as ohsix
=== psivaa_ is now known as psivaa
[10:00] <ppisati> brb
[10:11] <Caribou> Any reason why ubuntu kernel packages are marked "Priority:optional" ?
[10:11] <Caribou> is it because it is not mandatory to install newer kernels (mandatory == automatic) ?
[10:14] <davmor2> Caribou: I'm assuming it is because you may not want/limit downtime on a server so being able to plan a kernel upgrade post testing is important, you don't want your system to die because it got installed with the security updates
[10:15] <Caribou> davmor2: yeah, that's sort of what I understood. We want to keep control over how kernel are upgraded
[10:15] <Caribou> davmor2: thanks
=== fmasi is now known as fmasi_afk
[12:27]  * henrix -> lunch
[12:29] <nessita> diwic, hello there. So, I installed the PPA yesterday, rebooted this morning, and tried to reproduce the bug. Sound does not work at all, not even the mic, and I can not hear anything (not even for some minutes). In any case, I uploaded the syslog with the verbose pulseaudio content to the bug
[12:49] <ogasawara> apw_: can you refresh my memory for why we suppressed the -extra's package for mainline builds?
[12:50] <diwic> nessita, hmm, okay
[12:51] <rtg> ogasawara, why do we need that level of confusion ? extra's just tends to confuse folks
[12:51] <rtg> plus its kind of a maintenance hassle
[12:52] <ogasawara> rtg: a maintenance hassle for the mainline builds?  I thought that's just a cron.
[12:52] <rtg> ogasawara, new upstreams often cause missing modules or missing symbols in the main package.
[12:54] <rtg> ogasawara, is someone hassling you about the size of the mainline package ?
[12:54] <apw> ogasawara, casue they were confusing and not needed, and it was hard to make sure the right combinations were in the non-extras without knowing in advance the depandancies which caused it to fail to build
[12:54] <apw> who is caring
[12:55] <ogasawara> rtg, apw: Intel is trying to bisect that Romley boot issue for me and notes that the mainline builds fail while 3.10.0-4 from a daily live image is working and they were interested if it might be due to the lack of installing the linux-image-extra's package
[12:55] <ogasawara> rtg, apw: which might indicate we are missing a boot essential module out of the main package
[12:56] <rtg> ogasawara, they should be using 'make deb-pkg' as their build target during bisection.
[12:56] <diwic> nessita, argh, it might be that the logging itself causes too much CPU power, so Pulseaudio ends up getting killed
[12:56] <diwic> nessita, this bug is doing everything it can to escape us it seems 
[12:57] <nessita> diwic, bad bug, bad
[12:58] <rtg> ogasawara, 'deb-pkg' bypasses all of our packaging issues. they only need the initial config.
[12:58] <diwic> apw, what does a "trap int3" message from the kernel mean?
[12:58] <apw> diwic, what is the fulle message
[12:59] <diwic> apw, from syslog: "kernel: traps: alsa-source-ALC[4882] trap int3 ip:xxxxx sp:xxxxx error:0" (where xxxx are hex addresses)
=== smb` is now known as smb
=== fmasi_afk is now known as fmasi
[13:08] <rtg> apw, I'm wreaking havoc on saucy unstable this morning. reorganizing and squashing a bunch of commit log noise.
[13:10] <rtg> apw, trying to bisect amongst our SAUCE patches to figure out what borks my SNB server boot has made me realize was a disorganized mess our commit history has become. I'm in full OCD mode for a bit.
[13:23] <apw> rtg, ok i am sitting on my hands till you tell me otherwise unstable relaed
[13:23] <rtg> apw, ack
[13:43] <apw> rtg, in better news, the recent rebase you did to a commit post -rc2 has fixed up my ultrabook boot
[13:43] <rtg> apw, cool
[13:45] <nessita> diwic, anything else we/I can try on the audio front?
[13:45] <apw> rtg, and that version seems to start my VMs ok as well
[13:45] <apw> rtg, so i am be searching for something that isn't worth finding here
[13:45] <diwic> nessita, oh sorry. I got caught up with other stuff. 
[13:45] <rtg> apw, isn't that what you and jdstrand were fighting yesterday ?
[13:46] <apw> yeah, i was unable to boot 3.11 on the machine experiencing the issueyesterday
[13:46] <apw> your new one today i can
[13:46] <diwic> nessita, it looks like the "scheduling delays of ... ms" does not show up in this version, which is annoying
[13:46] <apw> rtg, though i have variously discovered that changing the video and changing the network can help in the VM
[13:46] <apw> so it is all a bit mad
[13:46] <rtg> apw, yeah, some of the post -rc2 patches were pretty meaty
[13:47] <diwic> nessita, can you try the non-syslog version of logging (i e, to a file, like wiki.ubuntu.com/PulseAudio/Log says) ? Maybe that won't take so much CPU power.
[13:48] <nessita> diwic, need me to revert to older pulseaudio?
[13:48] <diwic> nessita, with this new pulseaudio
[13:48] <nessita> diwic, will do
[13:55] <nessita> diwic, me again. So, having pulseaudio running as per the wiki, when opening mumble, I got:
[13:55] <nessita> nessita@dali:~$ LANG=C pulseaudio -vvvv --log-time=1 > ~/pulseverbose.log 2>&1
[13:56] <nessita> Trace/breakpoint trap (core dumped)
[13:56] <nessita> it died
[13:56] <nessita> want the verbose log?
[13:59] <diwic> nessita, oh
[14:00] <diwic> nessita, install gdb and run "gdb --args pulseaudio -vvvv"
[14:00] <nessita> on it
[14:00] <diwic> nessita, you'll come into a gdb shell, where you write "r" to run the program.
[14:00] <diwic> nessita, hopefully it will catch the trap
[14:01] <nessita> Program received signal SIGTRAP, Trace/breakpoint trap.
[14:01] <nessita> [Switching to Thread 0x7fffed380700 (LWP 3580)]
[14:01] <nessita> 0x00007fffedbad451 in ?? () from /usr/lib/pulse-4.0/modules/libalsa-util.so
[14:01] <diwic> argh
[14:01] <nessita> w will not show a traceback
[14:01] <nessita> ah, newer gdb
[14:01] <nessita> where shows;
[14:01] <nessita> https://pastebin.canonical.com/94962/
[14:02] <nessita> diwic, ^
[14:02] <diwic> nessita, hmm. I'll need to make a new PPA build
[14:02] <nessita> diwic, happy to try it
[14:03] <nessita> diwic, shall I attach to the bug the verbose log before the crash?
[14:03] <diwic> nessita, if you like
[14:03] <diwic> nessita, I think it breakpoints on underruns
[14:05] <nessita> diwic, is that something from 1.4 or from your custom code?
[14:07] <diwic> nessita, it's from enabling DEBUG_TIMING which gives us useful output
[14:07] <nessita> ah
[14:09] <nessita> diwic, do you need something else from the gdb session? tracebacks from the threads? (I see 3 threads)
[14:09] <diwic> nessita, okay, I uploaded a new build to the ppa.
[14:09] <diwic> nessita, no, let's wait for the new build. 
[14:10] <nessita> ack then. When built will upgrade and re-test
[14:10] <nessita> thanks!
[14:10] <diwic> nessita, btw, if the lack of audio is causing you a lot of trouble, have you tried a USB headset? It might work better, but I'm unsure, because the system latencies could affect that one too
[14:11] <nessita> diwic, so far I'm workaround this with my phone using skype or hangouts there
[14:11] <nessita> workarounding*
[14:11] <nessita> diwic, I have a bluetooth headset, I may give it a try
[14:11] <diwic> yeah
[14:11] <diwic> that's worth a try
[14:12] <nessita> diwic, not sure if this is relevant, but I hit 'c' in the gdb session, before exiting, and got more info https://pastebin.canonical.com/94965/
[14:13] <nessita> there are some "overrun" there, so perhaps is interesting for you
[14:13] <diwic> nessita, yeah, it confirms the trap happened due to the overrun
=== brendand_ is now known as brendand
[14:59] <brendand> bjf, regression in precise SRU testing: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1199470
[14:59] <ubot2`> Ubuntu bug 1199470 in Kernel SRU Workflow certification-testing "linux: 3.2.0-50.76 -proposed tracker" [Medium,In progress]
[14:59] <brendand> bjf, sorry - the actual bug is: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1204548
[14:59] <ubot2`> Ubuntu bug 1204548 in linux (Ubuntu) "[HP ProBook 6550b] can't send files via Bluetooth" [Undecided,New]
[15:00] <bjf> brendand, looking
[15:05]  * apw watches his firewall root disk go bad before his very eyes
[15:05] <apw> what else can go wrong htis week, i wonder
[15:06] <rtg> git checkout -f un
[15:06] <rtg> -EWRONGWINDOW
[15:14] <arges> question for those that understand the backports packaging
[15:14] <arges> i see bug 1194121
[15:14] <ubot2`> Launchpad bug 1194121 in linux-meta-lts-quantal (Ubuntu) "linux-meta-lts-quantal should provide a kernel sources package" [Undecided,Confirmed] https://launchpad.net/bugs/1194121
[15:15] <arges> Basically if I'm running 12.04.2 with the quantal-lts backport kernel, I would expect apt-get linux-source to install the 3.5 sources instead of the 3.2 sources right?
[15:15] <rtg> arges, why ?
[15:16] <rtg> apt-get doesn't know (or care) what kernel you're running.
[15:16] <arges> rtg: right, but wouldn't a user expect linux-sources to install the same version of the kernel that's runnin
[15:18] <rtg> arges, no. linux-source is packaged by linux (the source package).
[15:19] <arges> Ok. so then would it make sense for the lts-quantal package provide a linux-source-*-lts-quantal package?
[15:20] <rtg> arges, perhaps, but we chose not to at the time the LTS packages were developed.
[15:20] <rtg> arges, what is your use case ?
[15:30] <bjf> brendand, are you or someone else going to be around to test kernels?
[15:31] <brendand> bjf, you want to be in touch with our lab engineers - roadmr and spideyman
[15:31] <bjf> brendand, can you ask them to join this channel?
[15:31] <brendand> bjf, yeah
[15:32] <brendand> bjf, i'm currently writing instructions on how to reproduce it on the bug
[15:37] <brendand> bjf, spideyman and roadmr can help
[15:37] <bjf> brendand, spideyman, roadmr thanks, i'll have a kernel to test in about 15 min.
[15:38] <bjf> maybe sooner
[15:38] <roadmr> bjf: awesome!
[15:38] <brendand> bjf, oh do you have a commit that's suspect already?
[15:38] <bjf> brendand, yes, one kind of "jumps out"
[15:39] <brendand> bjf, do you want me to mark the kernel 'certification-testing-failed'?
[15:39] <bjf> brendand, sure
[15:49] <bjf> roadmr, pleast try: http://people.canonical.com/~bradf/1204548/
[16:15] <roadmr> bjf: downloading kernel (sorry for the delay)
[16:21] <ppisati> brb
=== fmasi is now known as fmasi_afk
[16:41] <bjf> roadmr, given https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1204548/comments/5 is this a kernel bug or a bug in the test tool?
[16:41] <ubot2`> Ubuntu bug 1204548 in linux (Ubuntu) "[HP ProBook 6550b] can't send files via Bluetooth" [High,Confirmed]
[16:42] <roadmr> bjf: the test tool doesn't change, all I do is reboot with a different kernel
[16:42] <bjf> roadmr, i understand that, but you say using obexftp fails, using the panel applet works
[16:42] <roadmr> bjf: I'd understand if the tools poked the bluetooth stack differently, so one of them exposes a problem and the other does not, but it seems like *something* changed in the kernel that's making obexftp unhappy
[16:44] <bjf> roadmr, yes but it could be that obexftp was doing something it shouldn't and getting away with it before. now that has been tightened up in the kernel and obexftp is failing.
[16:48] <roadmr> bjf: good point... well, the BluetoothRevert kernel works fine, obexftp can send OK with that one, whereas with the -proposed one it fails (and further, with the .49 one in -updates it also works well)
[16:48] <bjf> roadmr, so we know the commit to revert, we just need to decide if it's a userspace issue or not
[16:50] <roadmr> bjf: hmm yes that makes sense
[16:52] <bjf> roadmr, can you add the version of obexftp that you are running to the bug?
[16:53] <roadmr> bjf: fwiw, obexftp has worked well on all other releases we test (quantal, raring). Precise 3.2.0-50.76 is the only one that failed
[16:53] <roadmr> bjf: certainly
[16:54] <bjf> roadmr, i'll look at the other releases but i'm thinking that commit may make it into the others if it isn't there already
[17:14]  * rtg -> lunch
[17:23] <roadmr> bjf: ok, sorry for the delay, last kernels we tested were 3.5.0-37.58 (quantal), 3.8.0-27.40 (raring)
[17:24] <bjf> roadmr, that commit is in raring as well. i'm leaning towards reverting that commit for precise and looking at reapplying it for the next cycle. there are a couple other commits that may fix the issue you are seeing.
[17:26] <henrix> bjf: are you talking about commit c15a1f053c753c375d1d61fdd3a77bcfcb305bfa (in precise)?
[17:26] <henrix> bjf: i just took a look and it looks like there's a fix on top of it (not sure if it solves the prob)
[17:26] <henrix> bjf: upstream commit 3f6fa3d489e127ca5a5b298eabac3ff5dbe0e112
[17:26] <bjf> henrix, yes, and yes i saw that "fix"
[17:26] <henrix> bjf: its already queued for stable 3.2
[17:27] <henrix> bjf: ah, ok :)
[17:28] <bjf> roadmr, i'll spin another kernel for testing in just a sec. probably take about 30 - 45 minutes
[17:30] <roadmr> bjf: awesome, I'll step out for lunch while that's building, back in a bit!
[17:41] <rtg> apw, I guess I'm done exercising my compulsions on saucy unstable for now. all pushed...
[17:42] <rtg> back to bisecting why my server won't mount /home
[18:00] <rtg> apw, dang. rebasing to Linus' tip fixed my mount problem. 
[18:04] <bjf> roadmr, new kernel, same location: http://people.canonical.com/~bradf/1204548/
[18:13] <roadmr> bjf: awesome, thanks, downloading now...
[18:28] <roadmr> bjf: ok, the fixup kernel also works using obexftp.
[18:29] <bjf> roadmr, this one you just now tested?
[18:29] <roadmr> bjf: yes
[18:29] <bjf> roadmr, cool, i think that all
[18:30] <roadmr> bjf: so to recap, 3.2.0-49.75 from updates works well, 3.2.0-50.76 from proposed fails, the BluetoothRevert works well, BluetoothFixup also works well
[19:54]  * rtg -> EOD