[08:09] <ppisati> moin
[08:47]  * apw waves to ppisati
[08:59]  * smb waves to apw and ppisati 
[09:00] <apw> moin
[09:01]  * apw notes that mounting encrypted drives is "not allowed again" and mumble is broke, and until my update completes i cannot reboot for either
[09:04] <smb> apw is truly in Monday hell
[09:10] <apw> truly indeed
[09:10] <apw> though i have tea, so something is ok
[09:16] <apw> things _seem_ to be working ok
[09:18] <smb> (famous last words)
[09:19] <apw> all true
[10:31] <ppisati> brb
[12:11]  * henrix -> lunch
[12:29] <ogra> apw, bug 1113396
[12:29] <ubot2> Launchpad bug 1113396 in linux-nexus7 (Ubuntu) "syslog spammed with cpu_up/cpu_down messages after upgrade to linux-nexus7 3.1.10-9.24" [Wishlist,New] https://launchpad.net/bugs/1113396
[12:30] <ogra> not sure if there is an easy way to quieten it
[12:33] <apw> ogra, i am not sure i would expect to see the kernel turning its own cpus on and off
[12:35] <ogra> well, i dont think the interactive giovernor is a mainline thing 
[12:38] <apw> ogra, and which version was this ok in ?
[12:38] <ogra> none, we only switched to interactive pretty recently
[12:38] <apw> ogra, as i was runing .24 and it was not saying it, i rebooted to run .25 and it is ...
[12:38] <apw> ok so this is triggered by a userspace change
[12:39] <ogra> the governor code itself is noisy, i assume android simply de-routesd the messages into their own log or so
[12:39] <ogra> right, it is triggered by actually activating the governor
[12:40] <ogra> (interactive means there is userspace config, we only put that into place recently (it is identical with teh android setup now))
[12:40] <ogra> see /etc/init.d/ondemand on an up to date nexus7
[12:40] <apw> ogra, so all of these messages are at standard low levels, so they won't appear on the console
[12:41] <apw> ogra, but they will be logged to dmesg, and then to syslog indeed
[12:41] <ogra> yes, but they make dmesg unreadable 
[12:41] <ogra> and syslog, yeah
[12:43] <apw> those messages are key messages during boot so one knows that your CPUs have come up right
[12:43] <ogra> its the dynaminc "core up/down" messages that are noisy
[12:44]  * ogra  doesnt care about boot ... but about readable logs :)
[12:44] <apw> you will if it doesn't
[12:44] <ogra> heh, indeed
[12:44] <apw> and this has a measurable difference in something which makes it worthwhile
[12:45] <ogra> definitely 
[12:45] <ogra> with all other governors i have a constant system load above 1.0
[12:45] <ogra> its the only way to get the CPU to behave sanely it seems
[12:45] <apw> other than load, which could well just be a lie
[12:46] <ogra> battery life definitely is extended (i didnt measure exactly how much yet, but it is noticeable)
[12:46] <apw> ok i'll have a think about it
[12:46] <ogra> i marked it as wishlist for a reason though ... its not super high prio
[12:47] <ogra> (i guess you can filter with grep/sed/whatever if actually needed)
[13:40] <brendand> henrix, when are you spinning the next -proposed kernels?
[13:41] <henrix> brendand: a new SRU cycle just started
[13:41] <henrix> brendand: so, we should have new kernels in -proposed by EOW
[13:41] <brendand> henrix, so the testing week will be 18th to 22nd?
[13:42] <henrix> brendand: yes, i believe so
[15:03]  * infinity eyeballs the oneiric SRU...
[15:03] <infinity> henrix: I thought we were taking an SRU break? :P
[15:03] <henrix> infinity: i believe that break is now over :)
[15:03] <infinity> Huh.  Time flies.
[15:04] <infinity> Though we're still skipping this one for P/Q, I guess?
[15:04] <henrix> infinity: we skiped one cycle only, so... a new one starts this week
[15:04] <infinity> Or just queueing things up in the PPA, but not accepting them.
[15:04] <infinity> So as to not disrupt 12.04.2
[15:05] <henrix> infinity: no, i believe we're rolling all the kernels this cycle. we have a bunch of stuff already in master-next branches. time to flush, i believe :)
[15:05] <henrix> but i may be wrong :/
[15:05] <henrix> bjf: any thoughts? ^^^
[15:06] <infinity> Well, precise is frozen until release, so you can roll what you want, but it's not going anywhere.  That's all.
[15:07] <infinity> (And it releases in 10 days)
[15:07] <infinity> So, that may be decent timing anyway.  I can do the PPA->proposed copies as soon as the release is out.
[15:08] <henrix> infinity: makes sense to me. but i'll confirm this with bjf once he's around. he may prefer to skip P again
[15:10] <infinity>    * ext4: quiet 'unused variables' compile warnings
[15:10] <infinity>      - LP: #1071314
[15:10] <infinity>      - CVE-2012-4508
[15:10] <ubot2> Launchpad bug 1071314 in linux (Ubuntu Hardy) "CVE-2012-4508" [Medium,New] https://launchpad.net/bugs/1071314
[15:10] <infinity> ^-- How on earth does that warrant a CVE?
[15:11] <henrix> infinity: where are you seen that?
[15:12] <infinity> henrix: Your changelog.
[15:12] <henrix> infinity: right, but in which kernel?
[15:12] <infinity> Probably just a copy-and-waste oops.
[15:12] <infinity> henrix: oneiric.
[15:12] <henrix> infinity: ok, let me check...
[15:13] <henrix> infinity: ah! so, the prob was that the fix for that CVE required some adjustments (this was commit dee1f973ca341c266229faa5a1a5bb268bed3531)
[15:14] <infinity> henrix: Stacked commits, fair enough.  Still seems like an odd way to attribute the bug, but I don't really care either. :P
[15:14] <henrix> infinity: so, the CVE fix contains 2 commits
[15:15] <henrix> infinity: yeah, i just added that to track the commit. i should probably add a note next time...
[15:44]  * ogasawara back in 20
[16:05] <bjf> infinity, unless something happens, I think we are skipping P and Q again this cycle. it means the following cycle is going to have a crapload of commits in those kernels.
[16:06] <infinity> bjf: That sounds fair to me.
[16:06] <bjf> hggdh, brendand, vanhoof ^
[16:09] <brendand> bjf - oh ok. so we're not looking at new P and Q until the beginning of march?
[16:09] <bjf> brendand, that's what it's looking like
[16:10] <brendand> bjf - what's the motivation exactly?
[16:11] <infinity> brendand: Not disrupting the point release.
[16:11] <bjf> brendand, if you read more of the scrollback you can see the discussion. it's about getting the .2 release out and not allowing P kernels into -proposed until .2 is released
[16:11] <infinity> bjf: To be fair, we COULD do the cycle as normal and let the kernels into -proposed, and just not promote them until post-release.
[16:12] <infinity> bjf: I'm open to that option too, since I'm the one who tends to do all the archive side anyway.
[16:12] <bjf> infinity, not promote them to where until post-release?
[16:12] <infinity> bjf: To updates/security.
[16:12] <bjf> infinity, they shouldn't go to updates/security until the following week anyway
[16:12] <brendand> bjf - ah yeah. i forgot that's delayed until next week
[16:13] <bjf> infinity, i thought you did all the point release "work up" in -proposed
[16:13] <infinity> bjf: We'll be switching image builds to -updates only pretty soon now.
[16:13] <bjf> infinity, when will that switch happen? what is "pretty soon now"?
[16:14] <infinity> Like, this week, maybe today or tomorrow.
[16:14] <bjf> bah!
[16:14] <bjf> henrix, hggdh, vanhoof, brendand I take it all back, we are turning the crank on everything.
[16:15] <bjf> infinity, if i can get into -proposed by next monday, that's good enough for us
[16:15] <hggdh> bjf: ack :-)
[16:16] <infinity> bjf: Alright.  I may artificially delay for a few days to make sure all our point release ducks are in a row, but "by next Monday" seems entirely reasonable.
[16:17] <henrix> bjf: ack
[16:18]  * bjf feels much better only skipping a single cycle
[16:20]  * infinity is reminded that he needs to do a d-i upload to precise for the last SRU round...
[16:27] <antarus> yes please don't forget poor little precise ;p
[17:01]  * ppisati -> gym
[17:20] <bjf> ogasawara, i'm starting to look at the release notes for 12.04.2. have you done anything there yet?
[17:20] <ogasawara> bjf: not yet, but it is on my todo list for today
[17:20] <bjf> ogasawara, so i can just ignore it :-P
[17:21] <bjf> ?
[17:21] <ogasawara> bjf: yah, let me take a first stab at it.  I'll probably ask you to review/edit tomorrow.
[17:21] <bjf> ogasawara, wfm
[18:00] <ohsix> where do i get me a vmlinux for perf nowadays, last time i had to do it it was ugly and it didn't end up in /boot and stuff
[18:04] <jsalisbury> apw, ogasawara should 3.8.0-4 have a linux-tools package?  I see the latest one available is linux-tools-3.8.0-2 .  bug 1115047 was opened for this
[18:04] <ubot2> Launchpad bug 1115047 in linux (Ubuntu) "perf tool missing for Linux 3.8.0 (raring)" [Medium,Confirmed] https://launchpad.net/bugs/1115047
[18:05] <apw> jsalisbury, i think i would expect us to be able to make one, it was off because it needed libraries from universe, but i thought tim fixed that
[18:06] <jsalisbury> apw, Actually, I think I see it here: https://launchpad.net/ubuntu/raring/amd64/linux-tools-3.8.0-4
[18:07] <apw> jsalisbury, indeed we do seem to be building one
[18:07] <jsalisbury> apw, and it seems accesible from https://launchpad.net/ubuntu/raring/+source/linux
[18:07] <ogasawara> commit fdfb1fd6dccabf8ff4f4979d01d4f47b47fc5994
[18:07] <ogasawara> Author: Tim Gardner <tim.gardner@canonical.com>
[18:07] <ogasawara> Date:   Thu Jan 10 12:41:32 2013 -0700
[18:07] <ogasawara>     UBUNTU: [packaging] Add macro to selectively disable building perf
[18:07] <ogasawara>     
[18:07] <ogasawara>     Fixes FTBS until libaudit-dev is promoted to main.
[18:07] <ogasawara>     
[18:07] <apw> so the report must be wrong now at least
[18:07] <ogasawara>     Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
[18:08] <apw> ogasawara, i think the right thing to do is not MIR anything, but to pull tools out of the main kernel package
[18:08] <apw> ogasawara, i did start looking at it, or more specifically looking at the version in debian where they do the same thing
[18:08] <apw> and i think it is probabally viable, at least then it can link to anything
[18:09] <ogasawara> apw: makes sense to me to separate it
[18:09] <apw> jsalisbury, ok so we have a package, but no perf in it, so the bug is technically correct
[18:09] <jsalisbury> apw, ok, thanks
[18:09] <apw> jsalisbury, can you assign that bug to me, and i'll try and make a proper determination tommorrow
[18:09] <apw> jsalisbury, as to whether we can just rip it out
[18:10] <jsalisbury> apw, will do.
[18:10] <jsalisbury> ogasawara, apw, thanks!
[18:45] <vanhoof> bjf: wasnt attached to  this session, turning the crank due to regression?
[18:46] <bjf> vanhoof, all good here. we are turning the crank on everything this week. 
[18:46] <vanhoof> wont change 12.04.2 will it?
[18:46] <bjf> nope
[18:46] <vanhoof> gotcha
[19:07] <apw> diwic, i have a n7 wh
[19:07] <apw> diwic, which is refusing to make noises
[19:08] <diwic> apw, did you see today's update to bug 1068804 ?
[19:08] <ubot2> Launchpad bug 1068804 in ubuntu-nexus7 "sound only works after suspend/resume cycle" [Critical,In progress] https://launchpad.net/bugs/1068804
[19:08] <apw> diwic, that is the kernel i am running
[19:09] <apw> and it doesn't work before or after a s/r now
[19:09] <diwic> apw, so you're running a kernel with the patch from comment 31?
[19:10] <apw> diwic, yes, that is why i am whining at you
[19:10] <ogra> diwic, works fine for me ...
[19:11] <ogra> but andy seems to suddenly have sound issues (though that looks more like userspace)
[19:11] <apw> 1/2 isn't a good balance
[19:11] <diwic> so ogra and apw have both independently compiled their own kernels with the patch from comment #31, with completely opposite results?
[19:11] <apw> ogra, can i have your asounds.state ...
[19:11] <apw> diwic, no i made the kernel for both of us
[19:11] <ogra> diwic, nah
[19:11] <ogra> i was lazy
[19:12] <ogra> http://paste.ubuntu.com/1610080/
[19:12] <diwic> how about the alsa-store.conf override/disable, are both apw and ogra running that?
[19:12] <ogra> apw, ^^
[19:12] <apw> diwic, no idea what that is, so assume not
[19:12] <ogra> diwic, oh, i removed the override files :P
[19:13] <ogra> apw, whats the version of your ubuntu-defaults-nexus7 package
[19:13] <apw> 0.50
[19:13] <ogra> that doesnt have the override files
[19:14] <ogra> so we should be on the same page 
[19:14] <ogra> ls -l /etc/init/*.override
[19:14] <ogra> just to be sure
[19:14] <diwic> well, if the asound.state has become wrong it will be kept wrong without the overrides, that's a feature
[19:15] <ogra> yeah
[19:15] <apw> ls: cannot access /etc/init/*.override: No such file or directory
[19:15] <ogra> great
[19:15] <ogra> thats what we want
[19:16] <diwic> apw, let's have a look at your alsa info
[19:16] <apw> why don't we ship that damn script with the machine?
[19:16] <diwic> apw, /usr/share/alsa-base/alsa-info.sh
[19:16] <ogra> apw, because the driver needs to DTRT
[19:16] <diwic> IIRC
[19:17] <ogra> apw, the script is generated on first boot ... thats like asking why we dont ship 1G of different initrds on the CD for all possible machines
[19:17] <ogra> :)
[19:17] <diwic> are we talking about the alsainfo script or the asound.state script?
[19:17] <ogra> the state file
[19:18] <apw> diwic, i was talking about the one you showed me _was_ installed :)
[19:18] <apw> http://paste.ubuntu.com/1610099/
[19:18] <apw> diwic, ^^
[19:18] <diwic> apw, your speaker is muted
[19:19] <apw> great, its a shame none of the UI elements tell em that
[19:19] <diwic> apw, try muting and unmuting and see if it helps
[19:20] <apw> diwic, ok my speaker is no longer muted, but its still mut
[19:20] <apw> mute
[19:20] <diwic> ok
[19:21] <diwic> I've seen this happen a couple of times actually; the speaker alsamixer control spontaneously mutes itself. Probably some powersave feature or something
[19:23] <apw> diwic, damn this thing has a lot of mutes, any idea which of the 100s to try next?
[19:23] <ogra> int spk
[19:24] <apw> that is already 00
[19:24] <diwic> apw, don't try manipulating the 100s of mutiee
[19:24] <diwic> mutes, it's more likely to screw something up.
[19:25] <apw> oh any i twiddle i am putting back
[19:25] <apw> not that i have tried many
[19:25] <diwic> apw, instead try: delete asound.state and move away /etc/init/alsa-store.conf
[19:25] <ogra> you can cause pretty nasty results with that
[19:25] <diwic> apw, then power off the nexus7, wait a little while and put it back on.
[19:25]  * ogra remembers a full day with a squeeking n7 next to him until he got it back to a sane state 
[19:26] <diwic> hopefully that brings it into a sane state
[19:26] <ogra> and you couldnt adjust the volume ... and it started when the driver was initialized 
[19:27] <apw> diwic, ok will try that
[19:27] <diwic> ogra, what do you mean "couldnt adjust the volume"?
[19:27] <diwic> ogra, I mean, if it's muted it's muted
[19:27] <ogra> diwic, that was before you entered the project :) i played randomly with the mixer and got into such a state 
[19:28] <ogra> not even muting solved it 
[19:28] <diwic> ogra, aha, ok
[19:28] <ogra> the driver was just caught in a feedbackish squeek
[19:28] <ogra> i probably routed some random stuff to some other random stuff that should never have been connected :)
[19:29] <apw> diwic, ok now i have the volume plips, and the 'alert sound' previews back, but nothing for 'test sound'
[19:29] <ogra> just like hrw, i just didnt fry my speakers ;)
[19:29] <diwic> ogra, maybe we should hide more of those controls, all that we don't know what they do
[19:29] <diwic> apw, try pressing 'test sound' a few times
[19:29] <ogra> yeah, but thats extra work
[19:30] <ogra> theoretically people shouldnt touch alsamixer if pulkse works
[19:30] <ogra> or they should know what they do ...
[19:30] <apw> diwic, nothing obvious, i get the 'tink' to say i've hit Test, but no actual speaking bit
[19:31] <diwic> apw, yeah, for some reason the 'test sound' is sometimes a 'blupp' and sometimes 'front left'. Both count as success.
[19:31] <apw> diwic, really, thats ... not obvious
[19:32] <diwic> apw, I haven't investigated them.
[19:32] <apw> totem can't play an mp3 either
[19:33] <apw> even though it did install *-bad first time
[19:33] <diwic> apw, btw, speaking of funny alsamixer controls. Did you know what the one I disabled did? It was no regular control. It was a debug feature to set/get individual codec registers. Left channel was the codec register address, right channel was the data to get/set.
[19:33] <apw> heh now that is, er nice
[19:33] <diwic> apw, you can imagine what happens when alsactl tries to save/restore that kind of stuff.
[19:34] <apw> it is not going to end well for sure
[19:35] <apw> diwic, neither can rhythmbox even though it knows what it is
[19:35] <diwic> (especially as codec register address 0 was the default, and that likely causes some kind of codec reset. Not that what it does is really documented, just a guess.)
[19:35] <apw> so whatever those apps use is not connected to anywhere
[19:36] <diwic> apw, does rythmbox show up under applications in sound settings when it's playing something?
[19:36] <apw> yep, and full volumn
[19:36] <diwic> but no sound
[19:36] <diwic> ?
[19:37] <apw> that is correct
[19:37] <diwic> apw, while it plays back, try the test speaker feature again in sound settings, is it still working?
[19:38] <apw> diwic, nope
[19:38] <diwic> apw, can you go into alsamixer and see if "speaker" has muted itself again?
[19:38] <apw> diwic, alertsound still works
[19:39] <apw> diwic, as does plip on volume change
[19:39] <diwic> apw, so you have volume change 'plip' but not test speaker 'blupp'?
[19:39] <apw> correct
[19:39] <diwic> now that's a combination I've never seen before.
[19:40] <apw> diwic, speaker not muted
[19:42] <apw> diwic, i can only assume it is s/w somehow
[19:42] <diwic> apw, 'pactl list' output?
[19:42] <diwic> 'pacmd list'
[19:43] <apw> http://paste.ubuntu.com/1610165/
[19:43] <apw> http://paste.ubuntu.com/1610166/
[19:45] <apw> ok since running those two, if i start playback again i get like a nice chainsaw
[19:46] <apw> which is volume controlled
[19:47] <diwic> apw, yeah, it looks like it's constantly reconnecting to pulseaudio or something. Or that's my guess, given that rythmbox is "sink input #82" and I doubt that you've started 81 other clients before
[19:47] <diwic> but ogra has working rhythmbox?
[19:47] <ogra> i havent tried rb
[19:48] <ogra> i played a webm video, tried the test sound and have the plop from the volume up/down here
[19:49] <apw> client: 27 <Rhythmbox>
[19:49] <apw> diwic, ^
[19:49] <ogra> diwic, playing the HBR1 ambient station from RB now 
[19:49] <apw>     index: 111
[19:49] <ogra> works fine
[19:52] <apw> diwic, and quitting and restarting rb has gone back to silence
[19:54] <bjf> apw, your kernel is working for me
[19:54] <diwic> ogra, maybe we should add more alsamixer controls, put them first and call them "WARNING" and "DO NOT TAMPER" to avoid more people frying their speakers :-)
[19:54] <ogra> haha
[19:55] <apw> diwic, ahhh got it, i had to install -ugly
[19:55] <apw> diwic, when you try the first time it tells you to install -bad
[19:55] <apw> after you do that, it never says another thing
[19:56] <diwic> apw, now what do we think of RB doing that? Is it bad, or just ugly? :-)
[19:56] <apw> but without, it is just silent
[19:56] <apw> diwic, well it doing something dumb is ... ugly
[19:56] <apw> diwic, thanks ... and bjf thanks as well
[19:56] <diwic> apw, anyway, you got successful playback of mp3 files now?
[19:56] <apw> diwic, i do thanks, once you fixed my plips i was fixed
[19:58] <diwic> yw
[19:58] <bjf> apw, it seems to always come up "mute" when i reboot
[19:58] <apw> bjf, i thought we had a saver for that.  i'll give it a go next
[19:58] <diwic> bjf, is that with or without the alsa-store.conf override?
[19:59] <bjf> diwic, i've not done anything special other than install apw's kernel
[19:59] <ogra> sudo rm /etc/init/alsa*.override
[19:59] <apw> ls /etc/init.d/*.override
[19:59] <bjf> yes, those exist
[19:59] <ogra> remove them
[20:00] <ogra> they need to go away once the kernel is in
[20:00] <diwic> interesting, so then they do have a purpose
[20:00] <diwic> I was thinking pulseaudio was enough with storing/restoring volume
[20:00] <diwic> it should have been
[20:01] <ogra> it seems to store the volume here 
[20:01] <ogra> but still comes up muted
[20:01] <ogra> it is at full volume if i had it there and unmute after a reboot
[20:01] <diwic> maybe it has something to do with the spontaneous mutes of alsamixer controls, haven't really figured out why that happens and what to do about it
[20:02] <bjf> ogra, indeed, that seems to have "fixed" it. i rebooted and it came up in the same state (un-muted)
[20:02] <ogra> so the only bit left is the muting
[20:03] <diwic> apw, bjf so it looks like my patch actually fixes the no-sound-before-s3 problem, can I trust one of you to apply it to the official nexus7 kernel?
[20:04] <apw> diwic, yep i have applied it already, i'll be uploading it once i am happy the other fixes are good
[20:04] <apw> ogra, were you happy with dmesg
[20:04] <diwic> apw, thanks
[20:05] <ogra> apw, absolutely 
[20:05] <diwic> ok, got to do some laundry now, happy evening everyone
[20:05] <ogra> you too, and thanks !
[20:06] <diwic> :-)
[20:06] <diwic> bye!
[21:36] <ogasawara> bjf: I've taken a first pass at https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop
[21:37] <ogasawara> bjf: specifically the "LTS Hardware Enablement Stack" and "Ubuntu Kernel 3.5.0-23.35" sections
[21:37] <ogasawara> bjf: I still need to scrub the known kernel issues section
[21:38] <ogasawara> bjf: but let me know what additional edits I should make or info I should add
[22:01] <bjf> ogasawara, ack
[23:12] <vk1266> can anyone please suggest how I should check whether a particular LP bugfix has been applied to the mainline kernel?
[23:13] <bjf> vk1266, which LP bugfix are you referring to?
[23:14] <vk1266> LP: #1040557
[23:14] <ubot2> Launchpad bug 1040557 in linux (Ubuntu) "UEFI boot live-usb bricks SAMSUNG 530U3C,np700z5c laptop" [Critical,Fix committed] https://launchpad.net/bugs/1040557
[23:16] <bjf> vk1266, i can tell you that bugfix (or a variant of it) is in Linus' tree and was part of 3.8-rc6
[23:17] <vk1266> so I guess I am reasonably safe to try the mainline kernel on my Samsung, right?
[23:17] <bjf> vk1266, you are building the kernel from the sources yourself?
[23:18] <vk1266> no, I need to install deb's to verify if another bug still persists in the mainline kernel
[23:20] <bjf> vk1266, are they ubuntu debs?
[23:20] <vk1266> yes
[23:21] <bjf> vk1266, so for that bug you can see that the fix was released for oneiric, precise and quantal. so if you are installing a recent kernel from one of them you should be fine.
[23:22] <vk1266> bjf - perfect, thank you, that's what I needed to know. Now I am off to installing the mainline kernel for my Samsung and checking that other bug!
[23:22] <bjf> vk1266, wait!
[23:22] <vk1266> yes...
[23:23] <bjf> vk1266, there is a difference between an ubuntu kernel and a "mainline" kernel
[23:23] <bjf> vk1266, which "mainline" kernel are you installing? where did it come from?
[23:24] <vk1266> http://kernel.ubuntu.com/~kernel-ppa/mainline
[23:24] <bjf> vk1266, which mainline kernel are you going to install?
[23:24] <bjf> vk1266, that patch just went into mainline late last week
[23:26] <bjf> vk1266, if you are installing the v3.8-rc6-raring you should be ok
[23:27] <bjf> vk1266, is there a specific bug that you are testing that kernel for?
[23:28] <vk1266> I have quantal; I guess I cannot try v3.7-rc2, it is dated 20-Oct-2012 - must stick with 3.5.7.4
[23:28] <vk1266> I need to run the test for LP: #1114856
[23:28] <ubot2> Launchpad bug 1114856 in linux (Ubuntu) "power button not working when Samsung laptop is booted in CSM mode; works fine in EFI mode" [Medium,Confirmed] https://launchpad.net/bugs/1114856
[23:29] <bjf> vk1266, ok, hold off while i look at that
[23:30] <vk1266> Considering that 3.8 kernel is not yet available to my quantal installation, and that my current kernel is 3.5.0-23.35, I am wondering how much value will be in checking out 3.5.7.4
[23:31] <bjf> vk1266, i would not test a mainline kernel for that case. i'm going to add a comment to that effect.
[23:31] <bjf> jsalisbury, still around?
[23:32] <vk1266> thank you bjf! maybe I should try installing raring on my Samsung, but for just checking one bug it may be a little too much
[23:32] <bjf> vk1266, if you can wait, there will be a new Quantal kernel in -proposed by next week that might help
[23:33] <vk1266> sure I can -- if the LP bug waits for me
[23:34] <bjf> vk1266, i think there is a good chance it will still be around
[23:35] <vk1266> bjf, thank you - I will keep checking -proposed
[23:37] <vk1266> bjf, I am going to make a note in the LP bug to that extent
[23:45] <bjf> vk1266, sounds good
[23:47] <vk1266> bjf, I have posted a note to LP: #1114856 - thank you, I will now be checking -proposed and the mainline kernel ppa
[23:47] <ubot2> Launchpad bug 1114856 in linux (Ubuntu) "power button not working when Samsung laptop is booted in CSM mode; works fine in EFI mode" [Medium,Confirmed] https://launchpad.net/bugs/1114856
[23:47] <bjf> vk1266, ack, thanks
[23:56] <jsalisbury> bjf, hey
[23:56] <bjf> jsalisbury, hey, if you read the scrollback you get some indication of what i was going to mention
[23:57] <jsalisbury> bjf, ok