=== lamont` is now known as lamont
[03:18] <bryce> apw, so this cycle it appears Intel has again shifted to a new drm-whatever branch as the new cool thing they're asking users to test.  drm-intel-fixes
[03:19] <bryce> apw, the drm-intel-next-proposed branch seems to have been abandoned.  How irritating would it be to drop that branch and add drm-intel-fixes in the autobuilder?
[03:36] <ohsix> bryce: talk to Sarvatt, i think he knows more than you'd hope to ask about that :D
[03:38] <bryce> ohsix, I take it it's already been looked into?
[03:39] <bryce> I pm'd about it the other day in fact, but haven't gotten his reply yet
[03:39] <ohsix> about your question specifically i don't know, but he knows about all the trees and the intel drivers
[03:42] <bryce> ohsix, ok thanks.
=== smb` is now known as smb
[09:06]  * apw yawns ...
[09:13]  * cking offers apw some coffee
[09:13]  * apw offers cking a gold star
[09:13] <cking> how nice
[09:14] <apw> cking, we need a mumble tie breaker to know who is broken
[09:15] <cking> apw, what have you broken?
[09:17] <apw> cking, who knows, mine is above average in the working department normally
[09:17]  * apw cries
[09:18] <cking> apw is stuck in a twisty maze of pulse audio and mumble complexity
[09:19] <apw> cking, right i will have to reboot, but i have an update in flight ... so ... i'll be a while
[09:21] <smb> apw, Have you got the special pulse running there?
[09:21] <apw> nope
[09:22] <cking> what changed since yesterday (apart from a shed load of updates?)
[09:22] <smb> one thing that sometimes helps me is
[09:22] <smb> doing the usual killing of mumble and pulse
[09:22] <smb> then start mumble but not immediatly connect
[09:23] <smb> then go to config and set output to something like alsa
[09:23] <smb> apply and set it back to pulse
[09:23] <smb> then connect
[09:23] <smb> (of course apply going back to pulse too)
[09:32] <jk-> bah, mumble misbehaving
[09:32]  * jk- heads out
[09:39] <apw> bryce, ok switched that intel branch over to drm-intel-fixes
[09:41] <reisei> hi, all. I have a question about DSS. So, in 2.6.38 with bootarg omapdss.def_disp=dvi I can choose the default screen. I start the system and when I plug the cable, the image appears. In 3.0.13 screen stays black and goes to power-saving mode. How can I fix it in 3.0.13?
[09:45] <bryce> apw, sweet, thanks
[10:04] <Daviey> diwic: around?
[10:05] <diwic> Daviey, hi there
[10:06] <Daviey> diwic: heya
[10:06] <apw> diwic, Daviey has a mac 7,1 which is playing up
[10:06] <Daviey> diwic: so... i have a ma
[10:06] <Daviey> thanks apw 
[10:06] <Daviey> diwic: The sound, following a fresh boot - the audio plays sounds 'out of order'
[10:06] <apw> OH, Daviey this fix which went into that very very latest precice kernel
[10:06] <apw> thats for a 7,1
[10:06] <diwic> bug 909419
[10:06] <ubot2`> Launchpad bug 909419 in linux "[Several MacBooks (with PCI SSID 10de:cb89)] Choppy sound. Videos play double speed" [Undecided,Fix released] https://launchpad.net/bugs/909419
[10:07] <Daviey> So, for example, if i played audio saying "hello" the speakers would play "el-he-lo""
[10:07] <apw> Daviey, do you have Ubuntu-3.2.0-10.18 ... if not get that and test
[10:08]  * apw will be a bit dissapointed if it works :)
[10:08] <Daviey> 3.2.0-10-generic :(
[10:08] <apw> Daviey, check the # number
[10:08] <Daviey> err
[10:08] <apw> as the fix is only in the second -10
[10:08] <apw> Linux dm 3.0.0-16-generic #26
[10:09] <apw> that # number
[10:09] <Daviey> 3.2.0.10.10
[10:09] <Daviey> oh
[10:09] <apw> nope that linux-meta
[10:09] <Daviey> #17-Ubuntu
[10:09] <apw> ok, there is an update then
[10:09] <Daviey> updating
[10:09] <apw> diwic, you will be pleased to know i slipped your fix in with some security updates
[10:10] <apw> diwic, did you see anything about my mic in that dump by the way ?
[10:10] <Daviey> apw slips it in.
[10:10] <apw> f'nar
[10:10] <diwic> apw, security fixes for 3.2? or are you talking SRU here?
[10:11] <apw> diwic, yep for 3.2, vary rarely we get asked to expedite things out
[10:11] <apw> even into development
[10:14] <diwic> apw, so given the last bunch of testing (thanks for organising!), if I rebase my branch and add signed-off-by and remove "sound.git" where applicable, you think it's good enough to be merged before friday's upload?
[10:15] <diwic> the jack-detection branch (sorry for changing topic)
[10:15] <apw> diwic, arrrg ... got the link to that wiki page
[10:15] <diwic> https://wiki.ubuntu.com/Audio/PreciseJackDetectionTesting
[10:15] <diwic> cking just reported that his regression was fixed
[10:16] <diwic> apw, and still waiting for response from arges but I'd assume it's the same one
[10:16] <apw> cking, if your regressions are sorted can you fix your entry on the wiki ^^
[10:17] <cking> ack
[10:17] <apw> diwic, i think i lean to having it in if the testing is looking reasonable
[10:17] <diwic> apw, and xyzzyman I've been in contact with and his regressions are resolved as well
[10:17] <apw> as there is no better time than an alpha to get some testing
[10:18] <apw> diwic, ok can you update his entry or get him to, that helps with convincing people
[10:18]  * apw will test another box today at least
[10:19] <apw> diwic, ok the PPA has kernel and pulseaudio, what is the ramifications if just the kernel makes it in
[10:20] <ohsix> i think the kernel just enables the jack functionality to userspace, so without pulse the jacks wont work as a user expects
[10:22] <diwic> apw, hmm, I'd make sure PulseAudio makes it in if the kernel does, but for the hypothetical/transient question: in general same behaviour as it is currently 
[10:22] <diwic> apw, individual machines might get better jack detection
[10:23] <diwic> apw, but the kernel must go first in order not to regress
[10:23] <apw> i think mine does just with the kernel
[10:24] <diwic> does what?
[10:25] <ohsix> better jack detection
[10:25] <apw> i think my acer had better behaviour with just the kernel change
[10:25] <apw> i believe thats when it first split the volumes for headphone/speakers
[10:25] <apw> ok so... we need to go first anyhow
[10:27] <Daviey> diwic / apw: Doh, fresh boot - audio works fine.. thanks!
[10:27] <Daviey> I was sure i tried postional_audio already tho :/.. oh well.
[10:27] <apw> Daviey, users who moan when there is nothing wrong ... 
[10:28] <apw> Daviey, ,.. and can't do testing right :)
[10:29] <Daviey> apw: right.. damn slackers.
[10:30]  * apw goes find a patch to stop Daviey's machine working again is some other subtle way
[10:31] <Daviey> apw: honestly, there isn't much more you could do to make my experience less fun.
[10:31] <Daviey> :)
[10:32] <apw> :))
[10:32] <apw> Daviey, don't challenge me
[10:33] <Daviey> heh
[10:38] <diwic> apw, just so I get this right. You wanted old-commit, blank line, signed-off-by <me> line, cherry picked from <sha> line. Is that correct? 
[10:40] <diwic> or signed-off-by under the cherry-pick line?
[10:53] <apw> diwic, old commit commentry and signed off by _them_ // <blank> // (cherry-picked ...) // BugLink: (if any) // S-o-b: _you_
[10:53] <diwic> ok
[11:00] <apw> #define ACC_MODE(x) ("\004\002\006\006"[(x)&O_ACCMODE])
[11:05] <diwic> hmm, this one I wrote, so there's already a sign-off by me
[11:05] <rbasak> What's the plan on getting the fix for bug 920511 applied please (https://lists.ubuntu.com/archives/kernel-team/2012-January/thread.html#18628) I realise that the issue is more complicated but I can't automate the workaround so my dev cycle is like treacle right now. Can we just get the reversion into the archive and sort the details later?
[11:05] <ubot2`> Launchpad bug 920511 in linux-ti-omap4 "Regression: netinst on panda armhf fails" [Critical,In progress] https://launchpad.net/bugs/920511
[11:06] <rbasak> AIUI, 921137 prevents me from automating the workaround
[11:06] <rbasak> bug 921137
[11:06] <ubot2`> Launchpad bug 921137 in flash-kernel "Flash-kernel-installer doesn't support d-i debian-installer/add-kernel-opts in preseed " [Undecided,New] https://launchpad.net/bugs/921137
[11:07] <rbasak> This means that Ubuntu Server on ARM is uninstallable right now
[11:09] <apw> bug 920511
[11:09] <ubot2`> Launchpad bug 920511 in linux-ti-omap4 "Regression: netinst on panda armhf fails" [Critical,In progress] https://launchpad.net/bugs/920511
[11:13] <apw> rbasak, i am being told that the arm team don't want the revert in, which is why we are holding it, they are happy with the work arround
[11:13] <ppisati> rbasak: the arm decided for the booargs workaround, please ping orga/gruemaster/ndec/etctec
[11:14] <ppisati> rbasak: see yesterday #ubuntu-arm log for a disucssion about it
[11:14] <rbasak> OK, I wasn't aware of this. I'll speak to them - thanks
[11:14] <apw> rbasak, so you either need to get them to agree we apply the fix, or pound on whoever supports flash-kernel
[11:14] <rbasak> understood
[11:21] <diwic> apw, modified commit messages now pushed to http://kernel.ubuntu.com/git?p=diwic/ubuntu-precise.git;a=shortlog;h=refs/heads/jack-detection-backport . Verified that all patches are in Linus' tree with same SHAs. 
[11:22] <apw> diwic, excellent thanks
[11:35] <apw> bryce, ok the first build is done and published
[11:45] <apw> diwic, know anything about optimising mumble so it doesn't eat your machine alive ?
[11:46] <ppisati> back in 10mins
[11:51]  * apw drops to test a kernel
[11:59] <apw> diwic, so just testing your new kernel on an oneiric userspace
[12:00] <apw> diwic, and that also seemed to work, and gave me a new mic :)  the internal one, properly listed separatly
[12:00] <apw> diwic, with its own mute so i can mute the internal and not the external mic, nice
[12:15] <apw> diwic, ok on my dell the headphone is listed as unknown all the time, but does the right thing
[12:15] <apw> diwic, as in the destination changes as expected, but the kernel doesn't know
[12:15] <apw> (is that working or broken ??)
[12:47]  * apw pokes diwic
[13:53] <tgardner> herton, don't forget to upload Lucid LBM whilst doing the Lucid kernel
[13:53] <herton> tgardner, ok
[14:08]  * apw re-pokes diwic
[14:09] <tgardner> cking, are you able to mount ecryptfs file systems using the current 3.2.0-10 kernel ? I'm getting this in dmesg: 'Mount on filesystem of type eCryptfs explicitly disallowed due to known incompatibilities'
[14:11] <cking> tgardner, I'm running 3.2.0-10 fine with ecryptfs
[14:11] <tgardner> cking, how about if you do this: 'mkdir -p .junk junk;mount -t ecryptfs .junk junk' and accept the defaults ?
[14:12] <cking> lemme see
[14:13] <tgardner> cking, hmm, maybe its because its stacked. it works in /tmp
[14:13] <cking> works for me - but my home is not ecrypted
[14:14] <tgardner> cking, I first noticed this on a server where /home is not encrypted. lemme try there on /tmp
[14:15] <cking> tgardner, I get that now if I repeat those steps in my encrypted Private directory
[14:17] <tgardner> cking, how are you stuffing the keyring ? dmesg: 'ecryptfs_parse_options: You must supply at least one valid auth tok signature as a mount parameter; see the eCryptfs README'
[14:17] <cking> tgardner, this is where the pain begins
[14:18] <tgardner> cking, mount normally prompts for these inputs
[14:18] <cking> tgardner, fs/ecryptfs/main.c specifically checks that the lower fs is ecryptfs and then bails out with that error message "Mount on filesystem of type eCryptfs..."
[14:19] <tgardner> cking, I get that, but now I'm trying on a server with no ecryptfs file systems mounted.
[14:19] <cking> tgardner, and you still get that message?!
[14:19] <tgardner> this is something that used to work
[14:19] <tgardner> yes
[14:20] <tgardner> lemme make sure it works on gomeisa (which is lucid)
[14:21] <cking> tgardner, the README is rather impenetrable - I've not had much luck with the non-Private setup so far
[14:21] <ppisati> tgardner: don't pull the cma revert yet, there's one patch missing and i've two config diffs that can stuffed in the same upload (thermal management&c)
[14:22] <tgardner> ppisati, ack
[14:22] <tgardner> cking, hmm, same behavior on gomeisa, but its running a 3.0 kernel.
[14:23] <cking> tgardner, so how are you normally mounting this?
[14:25] <tgardner> cking, this used to work on a Lucid desktop, so the keyring may have been stuffed: mount -t ecryptfs .junk junk -o key=passphrase,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_passthrough=n,ecryptfs_enable_filename_crypto=y
[14:26]  * cking compares his runes he was using yesterday..
[14:27] <tgardner> cking, ok, it _still_ works on my Precise desktop, but only outside of the ecryptfs mount  point, e.g. /tmp
[14:27] <tgardner> so, I think my issue on the server is the keyring
[14:28] <tgardner> cking, can you send me your server runes ?
[14:28] <cking> hrm, however, I was banging my head against the wall trying to mount using: mount -t ecryptfs -o key=passphrase,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_passthrough=n,ecryptfs_enable_filename_crypto=y,passphrase_passwd=$ECRYPT_MOUNT_PASS $ECRYPT_PRIVATE_DIR $ECRYPT_CRYPTED_DIR
[14:29] <cking> I had no luck and hence discussed this with dustin last night but got side tracked today. Lemme install Lucid on a spare box and see if this works on that
[14:30] <tgardner> cking, I'd think a VM would work for testing this
[14:30] <cking> tgardner, yup, good idea, I've got powerful enough H/W
[14:33] <tgardner> cking, before you go to that trouble, lemme walk over to my server console and login. I'll bet this is a PAM vs SSHD issue.
[14:34] <tgardner> bbiab
[14:34]  * cking should config up a lucid box, so it's work that needs doing anyhow..
[14:37] <tgardner> cking, hmm, same behavior even after a login to the console. perhaps we should consult our local expert tyhicks
[14:38] <cking> tgardner, when he eventually comes on line later today then
[14:38] <cking> so it works on lucid for you?
[14:39] <tgardner> cking, only on a desktop. it didn't work on gomeisa
[14:40] <cking> I was having issues with this yesterday trying to make it work on top of a loop back mount - I wonder if this is a generic issue 
=== yofel_ is now known as yofel
[15:07] <ogasawara> tgardner, apw: I'm planning to pull in diwic's jack detection patch set and smb's reboot syscall patch for Alpha-2.  Anything else I'm missing?
[15:08] <apw> ogasawara, nothing i know of at the moment
[15:08] <diwic> apw, back. So if it's listed as unknown all the time (in PulseAudio), it might help with the PulseAudio in the PPA, if that does not help, well - there are still machines to fix
[15:08] <tgardner> ogasawara, has diwic pushed his fix? I've not seen the regression fix announcement come across the mailing list
[15:08] <apw> diwic, i am not concerned as the user consumable behaviour seems ok
[15:08] <diwic> apw, in particular machines using the model parsers inside the codec drivers, if that tells you anything
[15:08] <reisei> 7
[15:09] <apw> diwic, you should probabally send out a new pull request, as you have updated the patch commentary to make it pretty
[15:09] <diwic> tgardner, the only regression found in the kernel was pushed and resolved the issue
[15:09] <arges> diwic, hey that fix for pulseaudio worked for me. when your patches get in, will the pulseaudio package be updated as well?
[15:09] <apw> diwic, and there you can say whats good
[15:09] <diwic> tgardner, there have been two PulseAudio regressions whereas the second one is waiting to be build in a PPA.
[15:10] <apw> diwic, those are not in the 'existing' pulse i assume right? so if the kernel goes in they don't get tickled
[15:10] <diwic> arges, once the kernel is uploaded I'll try to push the new PulseAudio asap
[15:10] <apw> don't get triggered, only if you have the PPA pulse
[15:10] <ogasawara> diwic: I assume if I upload the kernel by Friday, will that give you enough time to coordinate the PulseAudio upload?
[15:11] <ogasawara> diwic: I can get it uploaded sooner if it helps
[15:11] <diwic> ogasawara, I'm counting on that; would that be Friday morning/evening US time?
[15:12] <ogasawara> diwic: I'd usually wait till the evening on Friday in case of any last minutes patches thrown at us, but I can do the morning if that's easier for you.
[15:12] <diwic> ogasawara, but yeah, doing it today or tomorrow gives me better margin
[15:12] <ogasawara> diwic: let me shoot for today.
[15:12] <diwic> ogasawara, excellent
[15:12] <ogasawara> diwic: that should then be built by tomorrow and I can still upload again on Friday if I need to.
[15:13] <apw> ogasawara, upload fun
[15:14] <ogasawara> apw: I'm just waiting for the OMG we need these patches that will roll in on Friday at 5pm because no one bothered to test until Friday at 4pm
[15:14] <apw> ogasawara, can i suggest we both have friday off, tgardner too
[15:15] <apw> that might learn em
[15:15] <ogasawara> heheh
[15:16] <tgardner> ogasawara, yeah, I might have to skip out Friday for a power day.
[15:16] <tgardner> powder*
[15:17] <ogasawara> tgardner: you been getting a lot of snow?
[15:17] <diwic> or a lot of babies ;-)
[15:17] <tgardner> ogasawara, we did, but its all gonna melt today. 40F plus high winds
[15:17] <ogasawara> tgardner: so you'll have a nice layer of ice over all that powder :)
[15:17] <tgardner> ogasawara, yep, it'll suck
[15:20] <ogasawara> diwic: just want to confirm git://kernel.ubuntu.com/diwic/ubuntu-precise.git jack-detection-backport is the correct branch to pull from and up to date with your latest changes?
[15:20] <diwic> ogasawara, that is correct
=== bdmurray_ is now known as bdmurray
[16:01] <tyhicks> tgardner: Hey - still having trouble with the eCryptfs mount command above?
[16:02] <tgardner> tyhicks, I'm about to send an email to you and kirkland` in a sec. 
[16:02] <tyhicks> tgardner: sounds good
[16:04] <tgardner> tyhicks, email sent
=== ogasawara is now known as Guest1558
=== ikonia_ is now known as ikonia
=== SpamapS_ is now known as SpamapS
[17:21] <tgardner> apw, git://github.com/sconklin/autotest.git
=== zz_bigbash is now known as bigbash
[17:46] <apw> ppisati, zinc should be better now
[17:47] <ppisati> cool
[18:28]  * ppisati -> out for some grocery
[18:34]  * tgardner -> lunch
[19:17] <elops> I've started to use zram(ubuntu package zram-config) and I've noticed it gets full and then it's no help any more.  So I wrote a script to run every 5min that swapoff/on all the zram swaps at once.  The attempt is to force the population of disk swap to free up zram swap for less persistent swapping.
[19:18] <elops> I beleve this is something that can better be handled by the linux VM machine, perhaps a component or sub-component of zram itself.
[20:57]  * tgardner -> EOD
=== kirkland` is now known as kirkland
[21:56] <kirkland> ogasawara: howdy!
[21:56] <ogasawara> kirkland: heya
[22:00] <jsalisbury> kirkland, o/  Good to see you around :-)
[22:02] <kirkland> jsalisbury: hiya bud!
[22:02] <kirkland> jsalisbury: *loved* the xmas card :-)  thanks!
[22:02] <jsalisbury> kirkland, glad to hear it :-)
[23:47] <bjf> ogasawara: heads up, i was playing with the security tests and one of them is hanging, the jjohansen is looking into it