[07:54] <psivaa> infinity: we have still to do linux-ec2/lucid and will try to do asap. sorry about the delay
[08:36] <ppisati> lp 1164074
[08:36] <ubot2`> Launchpad bug 1164074 in linux (Ubuntu Raring) "[Highbank] Quantal to Raring upgrade issues" [High,Confirmed] https://launchpad.net/bugs/1164074
[09:01] <ppisati> brb
[09:19] <apw> diwic, i have no sound on todays updates, on an all intel dell, 3 years old.  any suggestions as to diagnostics?  everything alsamixer shows for output is unmuted
[09:20] <diwic> apw, 13.04 ? did you have kernel and/or pulseaudio updates ?
[09:20] <apw> i had kernel at least, i had 450M so probabally most things
[09:20] <apw> for raring indeed
[09:21] <diwic> apw, let's assume kernel - last PA update was 3 weeks ago
[09:21] <apw> yay
[09:21] <apw> quality in action
[09:22] <diwic> apw, for initial investigation "ubuntu-bug audio" 
[09:27] <apw> diwic, https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1166097
[09:27] <ubot2`> Launchpad bug 1166097 in alsa-driver "[HDA-Intel - HDA Intel, playback] No sound at all" [Undecided,New]
[09:28] <diwic> apw, did you test speaker only or headphones too?
[09:29] <apw> diwic, i have personally tested all outputs, nothing
[09:31] <apw> infinity, yep
[09:33] <diwic> apw, but USB headset (if you're having any) is still working as usual I assume?
[09:33] <apw> diwic, don't think we have a usb headset here...
[09:33] <diwic> apw, ok.
[09:34] <apw> diwic, i do have some usb speakers, but they are not physically proximate
[09:34] <diwic> apw, let me look through recent patches to the driver and see if I find something
[09:36] <diwic> apw, argh, nothing there either
[09:36] <diwic> apw, I guess you're down to bisection then
[09:37] <diwic> apw, i e boot an older kernel to verify the kernel is the fault
[09:37] <apw> diwic, yeep
[09:37] <apw> diwic, daily quality guarenteed ... sigh
[09:38] <diwic> apw, how many days of update was it?
[09:41] <apw> diwic, a lot ... i have had no network for weeks, i was last 'here' with b/w about 2 weeks ago
[09:42] <apw> diwic, rebooting into a 3.5 kernel and i have sound
[09:49] <diwic> apw, you must have had sound with an earlier 3.8 kernel too?
[09:51] <apw> diwic, so ... 3.8-8 is ok, 3.8-9 is bad, i must have only used my usb output since then i assume to have not noticed for so long
[09:51] <diwic> apw, what dates are that approximately?
[09:52] <apw> commit 31b67ffaf4f9e72dce22d028180fc10a66dfec77
[09:52] <apw> Author: Tim Gardner <tim.gardner@canonical.com>
[09:52] <apw> Date:   Tue Feb 26 12:15:23 2013 -0700
[09:52] <apw>     UBUNTU: Ubuntu-3.8.0-8.17
[09:52] <apw> commit f7c0639bf5538a557a1f05ea6a81fb237776e2fa
[09:52] <apw> Author: Tim Gardner <tim.gardner@canonical.com>
[09:52] <apw> Date:   Thu Feb 28 08:47:51 2013 -0700
[09:52] <apw>     UBUNTU: Ubuntu-3.8.0-9.18
[09:55] <diwic> apw, what's the command for finding out the commits in between, for the sound/pci/hda directory?
[09:55] <apw> diwic, tricky cause it is a stable update ... ick
[09:55] <apw> git log 6071a7768562b970491c66127779de1f5b1250a3..Ubuntu-3.8.0-9.18 --oneline
[09:56] <apw> is the only changes we made ... so it must be a mainline change, working out what that is now
[09:58] <apw> diwic, it also includes 3.8 -> 3.8.1 stable
[09:59] <diwic> apw, hrm, I'm looking at gomeisa's ubuntu-raring tree and the only v3.8 tag it has is v3.8-rc5
[10:00] <apw> could be i have them locally separatly
[10:00] <diwic> apw, yeah, just haven't synced raring because I haven't got around to buy a bigger ssd :-)
[10:01] <apw> diwic, looking what was in the .1 updae
[10:02] <apw> diwic, 
[10:02] <apw> ca36807 ALSA: hda - hdmi: ELD shouldn't be valid after unplug
[10:02] <apw> 97ec241 ALSA: hda - Fix broken workaround for HDMI/SPDIF conflicts
[10:02] <apw> 13ba2f7 ALSA: hda - Workaround for silent output on Sony Vaio VGC-LN51JGB with ALC889
[10:02] <apw> 6a9c847 ALSA: hda - Fix default multichannel HDMI mapping regression
[10:02] <apw> 41e19bd ALSA: hda - Release assigned pin/cvt at error path of hdmi_pcm_open()
[10:02] <apw> 45d13ae ALSA: hda - Disable runtime PM for Intel 5 Series/3400
[10:02] <apw> looks to be the delta for hda
[10:03] <diwic> apw, I looked through all those already
[10:03] <diwic> apw, none of those looks applicable to your problme
[10:03] <diwic> i e your hardware
[10:03] <amitk> what does linux-image-extra contain (in the mainline builds) ?
[10:03]  * apw goes test that it _is_ 3.8->3.8.1
[10:04] <apw> amitk, 'the other half of your modules', linux-image is 'virtual' linux-image+l-i-extras is 'generic'
[10:04] <amitk> apw: so probably useful on a desktop
[10:05] <apw> amitk, indeed yes
[10:06] <amitk> apw: thx
[10:06] <apw> amitk, np
[10:06] <apw> diwic, identifying whether it is stable or our changes next
[10:06] <apw> will let you know
[10:07] <diwic> apw, thanks. Yeah, I think we're down to a real bisect at this point no matter what
[10:07]  * apw secretly blames diwic :)
[10:13] <apw> diwic, ok 3.8 mainline is good,  3.8.1 is bad
[10:14] <apw> diwic, what was my bug number?  i've lost it already
[10:15] <diwic> apw, bug 1166097
[10:15] <ubot2`> Launchpad bug 1166097 in alsa-driver (Ubuntu) "[HDA-Intel - HDA Intel, playback] No sound at all" [Undecided,New] https://launchpad.net/bugs/1166097
[10:22] <apw> diwic, ta
[10:32] <apw> diwic, so it is deffo one of those 6, just reverted just those off -9 and its working
[10:33] <diwic> apw, the annoying thing is that most of those are HDMI related 
[10:33] <apw> diwic, yes
[10:34] <diwic> apw, hmm, you do have an HDMI codec on the same sound card though
[10:34] <apw> diwic, it does have hdmi as well
[10:34] <diwic> apw, btw, I assume you have not tested HDMI audio?
[10:34] <apw> diwic,  i have not
[10:34] <apw> it is not something i use regularly
[10:37] <diwic> apw, ok. well, continue searching. My guess is "Fix broken workaround for.."
[10:38]  * diwic wonders if we'll need a "Fix for fix for workaround for" patch...
[10:41]  * diwic goes for lunch, bbl
[11:21] <diwic> back
[11:25] <apw> diwic, ok ... bisect says:
[11:26] <apw> commit ca368073ffcbdd25486d65c150039423f677f821
[11:26] <apw> Author: David Henningsson <david.henningsson@canonical.com>
[11:26] <apw> Date:   Tue Feb 19 16:11:22 2013 +0100
[11:26] <apw>     ALSA: hda - hdmi: ELD shouldn't be valid after unplug
[11:26] <apw> is at fault.
[11:29] <diwic> apw, eh
[11:29] <diwic> apw, ouch ?
[11:29] <diwic> apw, probably it triggers some other bug in a strange relationship
[11:39] <apw> diwic, what now :)
[11:42] <diwic> apw, I'm still in denial ;-)
[11:43] <diwic> apw, it's not a dangerous patch to revert
[11:43] <apw> diwic, i'll reset to latest kernel and confirm it reverting it there solves it too and its not just luck
[11:44] <diwic> apw, could you also attach the contents of /var/lib/alsa/asound.state to the bug?
[11:46] <apw> diwic, attached
[11:47] <diwic> apw, can't see it, are you sure the attachment uploaded correctly?
[11:48] <apw> diwic, try that (i hate LP)
[11:48] <diwic> now it's there
[12:11] <apw> diwic, ok confirmed that reverting that patch against the 3.8.0-16 base also fixes my issues.  am trying to debug now, as your patch seems reasonable assuming no other bugs
[12:16] <diwic> apw, it should only affect the output of a file under proc. 
[13:05] <apw> diwic, ok i have just added some prints (no functional change) on top of your not-working patch and it starts working ... this is well peculiar
[13:11] <diwic> apw, oh, a heisenbug
[13:11] <diwic> apw, out of curiousity what prints did you add?
[13:12] <henrix> brb
[13:12] <apw> http://paste.ubuntu.com/5689367/
[13:12] <apw> diwic, ^^
[13:12] <diwic> apw, also, I saw something in your dmesg; "alsa restore exited with status 99" or something similar. 
[13:12] <diwic> apw, do you know if this is related, i e, if this message only comes when it's working, non-working, or unrelated?
[13:12] <apw> diwic, interesting ..
[13:13] <apw> will check
[13:13] <apw> [   12.683939] init: alsa-restore main process (1436) terminated with status 99
[13:13] <apw> diwic, present when working as well
[13:13] <diwic> apw, okay
[13:13] <diwic> apw, then it's not that
[13:20] <smoser> can i poke someone about https://bugs.launchpad.net/bugs/1164739 ? i'm not sure if its regression or not, but at very least i'd expect a kernel package to not have missing dependencies inside it.
[13:20] <ubot2`> Launchpad bug 1164739 in linux "Can not mount cephfs in VM from cloud image" [Medium,Confirmed]
[13:24] <smb> smoser, Could require the extras package. Or someone asking to move certain modules to the main package...
[13:24] <smoser> smb, right. read my comment at the bottom.
[13:24] <smoser> i dont have strong feeling either way on that.
[13:24] <smoser> but ceph.ko should not be in a package if libceph.ko is not (as it former depends on latter)
[13:25] <smoser> i'd assert thats a packaging bug if significant priority. i'm surprised if humans are maintaining the kernel module list without automatic dependency resolution
[13:26] <smb> smoser, Right probably one or the other. I think there was at some point a request to have ceph in virt so if it is only 200k more I guess you or Ben would not mind the difference
[13:26] <smoser> smb, well, i'd like to see the justification.
[13:27] <smoser> 200k is not insignificant at all. installed size is ~ 12M, so 200k is 2% growth.
[13:28] <smoser> basically, i dont want to willy nilly be adding things there.
[13:28] <smb> smoser, That would be coming from the bug report, right? But yeah, it has not been a problem yet to maintain the list by hand. 
[13:28] <smoser> so it is maintained by hand, ok.
[13:29] <smoser> smb, ok. i'll open another bug that you can triage as you like for "module dependencies should not be managed by hand"
[13:30] <smoser> and then i'll ask the user here for some use case as to why they want ceph.ko in -virtual
[13:31] <smb> smoser, Yes, it is. Basically whenever someone tells us something needs to be supported in the cloud image we add it. 
[13:31] <smoser> we should have some sort of policy to guide us in such decisions 
[13:32] <smb> smoser, Hm, I am not sure this really qualifies (should not be done by hand). Whoever wants something now should test what is required. I wonder whether there was an actual request for ceph...
[13:35] <smoser> smb, well this user wanted ceph, but really only because they wanted to use ceph and didn't know about the -extra (and i told him).
[13:35] <smoser> clearly if you're given the choice between "do you want to have 1 extra step to use something" or "do you want to just use it", you'd pick the second.
[13:36] <smoser> but we have the size concern to consider.
[13:36] <smb> smoser, Its just that I *think* there has been someone asking for it before. I just cannot remember
[13:36] <smoser> smb, right.
[13:36] <smoser> smoser, can you git blame that list ?
[13:36] <smoser> and see?
[13:36] <smoser> at least who did it
[13:36] <apw> diwic, ok confirmed removing those printks also makes it break again
[13:36] <smb> smoser, thats what I currently try
[13:37] <smoser> smb, reguarding the dependency resolution, i'd suggest just failing a build if you're missing dependencies. 
[13:37] <smoser> there are no cases where that is not a bug.
[13:38] <diwic> apw, I assume the "restring cap" printk was never printed?
[13:38] <apw> diwic, correct
[13:39] <smb> smoser, Not sure this is that simple. At least now, the build is done completely and just the packaging step splits the modules up.
[13:40] <smoser> hm.. i dont know. but personally i'd rather have a developers build fail then have 'modprobe' fail on a user system in this way.
[13:40] <smb> smoser, http://bugs.launchpad.net/bugs/1063784
[13:40] <ubot2`> Launchpad bug 1063784 in linux "Ceph module not installed" [Medium,Fix released]
[13:41] <smb> So added around quantal
[13:41] <smb> But might be the other module did not exist then
[13:41] <smoser> smb, and then broken in raring to a kernel change probably.
[13:41] <smb> smoser, right
[13:41] <smoser> (which gives more credence to my argument :)
[13:42] <smoser> (the argument that there should be some test to stop this from being released)
[13:43] <smb> smoser, Hm, there is a libceph already (in q)
[13:43] <smoser> smb, the reporter claims this is broken in 12.10
[13:44] <smoser> that is a 3.5 kernel in the report.
[13:45] <smb> smoser, That would be Q, so someone did not test things after asking for it... :-P
[13:45] <diwic> apw, the thing is, eld->eld_valid should have been false always anyway, since you don't have an hdmi monitor plugged in.
[13:47] <smb> smoser, But ok, if it is possible to run a dep check on a package subdir that would catch those things
[13:49] <smoser> smb, its definitely doable. it might take some re-work of the kernel build though. i dont know.
[13:49] <smoser> but anyway.
[13:49] <smoser> i guess the right thing to do at the moment is to include libceph.ko
[13:49] <smoser> and probably sru that.
[13:51] <smb> smoser, Yeah, in theory it looks like one can point depmod at a different base dir and a system map file... so it should be possible. So let me know the bug for that. And for libceph, yes, sounds reasonable as having ceph.ko was already done, too.
[13:52] <smoser> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1166197
[13:52] <ubot2`> Launchpad bug 1166197 in linux "included kernel modules may miss dependencies (-virtual)" [Undecided,Confirmed]
[13:52] <smoser> smb, you definitely can do that. i use depmod that way in cirros
[13:53] <smb> smoser, Ok, I will try to add it to the build process then.
[14:05] <plars> infinity, bjf: we are almost through with the pile of SRUs from last week, there's a precise one that psivaa is working on now, and I'm about to start the ec2 one
[14:14] <bjf> plars, ack, looks good
[14:46]  * ogasawara back in 20
[14:55] <ppisati> infinity: i know you took care of the transition from Q/omap to Q/generic
[14:55] <ppisati> infinity: we need to the same for Q/highbank to Q/generic
[14:55] <ppisati> infinity: and i didn't find any patches in our kernel tree about it
[14:56] <ogra_> ppisati, meta should handle that
[15:00] <ppisati> ogra_: i know, but since he already handled that
[15:01] <ppisati> ogra_: he knows what to do better than me
[15:01] <ogra_> yep, i just mean it should be visible in your package somewhere :)
[15:06] <ppisati> actually was rtg who handled that
[15:06] <ppisati> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-raring-meta.git;a=commit;h=289b3dbee84086f2e323a1da7ccf3ea410b3ae59
[15:08] <ppisati> and i *think* we need a transitional pkg like we did for omap
[15:08] <ogra_> yup
[15:09] <ogra_> the right conflicts/replaces/breaks and a transitional package shoudl do
[15:21] <ppisati> ogra_: ok, i'll hassle rtg tomorrow about it
[15:21] <ogra_> :)
[15:46] <fxbrain> 
[16:01] <infinity> ogra_: No need for conflicts, breaks, or replaces, it's just a straight up depends.
[16:02] <ogra_> ah, k
[16:02] <ogra_> you dont want the old package to be removed ?
[16:02] <ogra_> even though its likely impossible to roll back
[16:03] <infinity> When the "old package" happens to be your running kernel, forcing it off the system would be a silly idea.
[16:03] <ogra_> ah, indeed
[16:15]  * ppisati -> gym
[16:15] <ppisati> later
[16:32] <infinity> psivaa: precise/omap4 seems to also be stuck in regression-testing.
[16:34] <psivaa> infinity: it's progressing now, started a little late on that and i should be able to finish it this eve. roughly in about 4 hrs
[16:34] <infinity> psivaa: Cool, thanks.
[21:00] <psivaa> infinity: just completed the regression testing task for linux-ti-omap4: 3.2.0-1429.38 (1160194)
[21:01] <infinity> psivaa: Danke.