[01:13] <bryceh> ogasawara, you might want to build a kernel for bug #614238; there's a confirmed patch that fixes it upstream.  
[01:13] <ubot2> Launchpad bug 614238 in linux "Intel Core i3 External Monitor Wavy Output" [Medium,Confirmed] https://launchpad.net/bugs/614238
[01:26] <bjf> bryceh, looks like stable kernels
[01:28] <bjf> bryceh, ah! i fully read your last comment
[01:45] <bryceh> bjf, right.
[07:48] <smb> morning .+
[07:54] <apw> smb, moin
[07:57] <cking> morning
[07:59] <apw> cking, hiya
[07:59] <apw> cking, hows it going ?  win ?
[08:00] <cking> yep, win
[08:05] <jk-> winning
[08:06] <jk-> hey all.
[08:34] <Fudge> hi not sure if this is right place to ask, ive noticed often on my gigabyte g41 motherboard with realtek onboard audio, i boot form live ubuntu cd's and have to unmute the audio. the same goes the  after install and again when new kernels are installed. is this normal? or is it something related to my sound server?
[08:36] <smb> Fudge, That would rather be the sound server (pulse). Though I dunno how to avoid it
[08:37] <Fudge> smb , its well known then?
[08:37] <apw> audio changing on installing a new kernel is a common issue, something to do with having to flush the previous settings in case they are are a different binary form on the new kernel
[08:38] <apw> in my case it always unmutes, which is even more annoying
[08:38] <cjwatson> Hi - could somebody try a kernel test build in precise with kernel-wedge 2.81ubuntu1 to see if it gets rid of bug 879340?  If so, a fresh upload at some point this week would be very helpful
[08:38] <Fudge> any bug reports or docs I can refer to on it?
[08:38] <ubot2> Launchpad bug 879340 in linux "nic-shared-modules ballooned in size in precise" [Undecided,Confirmed] https://launchpad.net/bugs/879340
[08:38] <apw> cjwatson, is that in the archive already (kernel-wedge) ?
[08:38] <cjwatson> yes
[08:38] <apw> cjwatson, ok will do
[08:38] <cjwatson> uploaded yesterday evening
[08:38] <cjwatson> thanks!
[08:39] <cjwatson> if it doesn't help, I'm a bit stumped on what caused the problem in that bug report and wouldn't mind debugging it with somebody
[08:39] <Fudge> apw  I use a script called Vinux which is for visually impaired, screen readers etc. We find it difficult when people install a system or update and they get no audio. you can prob imagine someone who is blind gets in a bit of a stick.
[08:39] <apw> yeah i cannot deny you have a bit of a problem if you are blind ...
[08:40] <apw> Fudge, my expectation is you'd have the opposite problem, so i'd think filing a bug would be reasonable
[08:40]  * smb wonders whether TheMuso has something working for him
[08:40] <apw> especially due to the accessiblity concerns
[08:40] <Fudge> yeah mate loL, its nice to know its not just somethign we've done though, we also currently use pulseaudio in system mode and that was a possible contributor
[08:40] <ogra_> apw, why is it not possible to just re-read the alsa state file after applying everythig ?
[08:40] <Fudge> TheMuso  is aware but i bug him enough
[08:40] <Fudge> i had the same thought, but implementing such a thing i have no idea
[08:41] <ogra_> that should get you back exactly what you had
[08:41] <Fudge> im a thinker, not a coder loL
[08:41] <apw> ogra_, re-read in what sense
[08:41] <ogra_> apw, alsactl restore
[08:41] <apw> ogra_, my understnading is it is a kernel specific binary form
[08:41] <Fudge> oh yes, automatically i mean
[08:41] <ogra_> its not
[08:41] <apw> and therfore not necessarily applicable safely
[08:41] <apw> whats in it
[08:41] <Fudge> and on a live cd it prob wouldnt work
[08:41] <apw> live cd yep, we are hosed
[08:41] <ogra_> look at /var/lib/alsa/asound.state
[08:42]  * apw would normally refer this kind of thing to david
[08:42] <smb> apw, I thought it was some sort of xmlish but not sure
[08:42] <Fudge> we have keybiindings to unmute but not everyone knows them and or use keyboards with media keys
[08:42] <ogra_> yeah, livecd is different, though we had a rule in tegh past to default to 80% volume, where is that gone ?
[08:42] <Fudge> ogra_  thank you but it would be a bit difficult for someone who cant do anything without sound
[08:42] <apw> ogra_, ahh it is text, but using kernel specific naming for the elements for the controls
[08:42] <Fudge> ah that sounds like a good idea
[08:43] <Fudge> maybe the rule went away
[08:43] <ogra_> apw, well, iterate over it once to see the controls still exist, then apply it
[08:43] <apw> ogra_, heh we may well default to 80% volume, but mute is separate, its not volume
[08:43] <ogra_> if controls went missing, dont apply it
[08:43] <apw> but we are well outside a kernel engineers comfort zone already :)  we need david
[08:43] <ogra_> it shouldnt happen that controls vanish/appear randomly ... at least on released installs
[08:44] <Fudge> i thought that when a volume is set if it was to 0 previously it would be unmuted
[08:44]  * Fudge calls for David :)
[08:44] <ogra_> i guess he's on vacation or traveling to UDS already
[08:45] <Fudge> left early?
[08:45]  * ogra_ hasnt seen him the whole week
[08:45] <Fudge> social time first, then work
[08:46] <Fudge> ill hang round, do u guys have a process where this may be able to be addressed? if appropriate
[08:46] <smb> Or he may be involved in DX?
[08:47] <apw> ogra_, yeah concur, not seen him this week
[08:47] <apw> Fudge, get a bug filed 'ubuntu-bug sound' and let us know the number
[08:47] <Fudge> apw  sure ill have a shot, url?
[08:48] <apw> just run 'ubuntu-bug sound' in a terminal
[08:48] <Fudge> oh kewl
[08:49] <Fudge> um, wouldnt i need to be on a system where the sound is experiencing problems?
[08:49] <Fudge> Package sound does not exist
[08:50] <smb> audio maybe?
[08:50] <smb> But yes, it would be better run from the affected system
[08:51] <Fudge> mm, ok
[08:51] <ogra_> and use an actual package name like alsa-utils 
[08:51] <ogra_> david will assign it to the right bit i guess
[08:51] <Fudge> actually, that may not help PulseAudio is running as a system-wide daemon.
[08:51] <Fudge> This mode of operation is not supported by Ubuntu.
[08:52] <Fudge> but ill try it on a ubuntu cd where pulse runs correctly
[08:52] <Fudge> thanx 
[09:43] <apw> cjwatson, seems that this new kernel-wedge has some new behavior in gencontrol, specifically if none of your kernels have an architecture specific builddep it no longer emits stub correctly
[09:53] <cjwatson> apw: OK, I'll fix that; can you modify gen-control locally or do you need an upload?
[09:54] <apw> cjwatson, i can work round it as i can make our configuration trigger the right behaviour
[09:55] <apw> cjwatson, i am assuming its a bug in detecting this "allow to be run by the source pacage" support but ... what its meant to really check i have no idea
[09:57] <cjwatson> it's because the Debian kernel packages don't have control.stub
[09:58] <cjwatson> apw: try http://paste.ubuntu.com/719554/ applied to /usr/share/kernel-wedge/commands/gen-control
[09:58] <cjwatson> if you can
[09:58] <apw> cjwatson, will do
[09:59] <apw> DatabaseError: database disk image is malformed
[09:59] <apw> lovely, seems pastebin is sick
[10:00] <bjf> apw, wfm
[10:00] <apw> bjf, click the text link at the bottom
[10:01] <bjf> apw, indeed
[10:01] <bjf> borked
[10:01] <bjf> it's python, what did you expect
[10:14] <apw> cjwatson, ok this will take a bit, tangerine just face-planted
[10:18]  * apw goes make some precise chroots on his local build machine ... sigh
[10:50] <apw> cjwatson, ok that patch seems to work as expected
[10:55] <ppisati> guys, can any of you have a look at 22bacca48a1755f79b7e0f192ddb9fbb7fc6e64e? this is the fix for cve 1082 and embedded in the commit msg there's the "proof-of-concept" that shows the vulnerability. Problem: it's either missing something (or it has been slightly borked to keep script-kiddies away) or i can't make it work.  
[10:59] <apw> ppisati, is this on hardy ?
[10:59] <ppisati> yep
[10:59] <apw> it is possible that hardy is immune for other reasons, like lack of features
[10:59] <ppisati> uhm
[10:59] <apw> have you tried it on a modern release with that commit reverted?
[11:00] <ppisati> sounds strange since epoll() is there
[11:00] <ppisati> uhm no
[11:00] <ppisati> ok, let me try
[11:00] <apw> my first reaction would be to confirm it works there
[11:00] <ppisati> ok, i'll try on lucid
[11:00] <apw> i am saying the implemntation of epoll() has changed, so it is entirly possible the exploit isn't valid
[11:00] <apw> and we _may_ not need to do anything on hardy
[11:01] <ppisati> uhm, actually having a "this commit has introduced this problem" could help inm this case
[11:01] <ppisati> anyway, let me see on lucid
[11:01] <apw> yeah they often know that info and don't put it in, which is annoying
[11:03] <apw> ppisati, one other thing, its possible that hardy say doesn't support adding epoll descriptors to themselves at all, i note that the exploit code does _not_ check the return codes from anything, perhaps strace it to see if any are failing
[11:03] <ppisati> did it
[11:04] <ppisati> i checked all the return code, and everything was ok
[11:04] <ppisati> from the commit msg it says 
[11:04] <ppisati> "this code leads to a deadlock" so i expected the exploit to hang
[11:04] <ppisati> but it just exit
[11:05] <apw> which could lead to deadlock"
[11:05] <ppisati> ok
[11:05] <ppisati> right
[11:05] <ppisati> could be racy
[11:05] <apw> dunno, unhelpful
[11:05] <ppisati> so me might never hit that case
[11:05] <ppisati> *we
[11:05] <apw> it is cirtanly unclear from that
[11:05] <ppisati> quantum-exploit
[11:06] <ppisati> sometimes it's true, sometimes it's not
[11:06] <apw> i think the point might be more that actually the example makes an invalid loop structure
[11:06] <apw> so it should work before the patches, and fail after the patches
[11:06] <ppisati> ah
[11:06] <ppisati> good point
[11:07] <apw> while epoll should keep working for non-loop structures
[11:07] <ppisati> after thge patch the "loop struct" should fail when it's created
[11:07] <ppisati> *structure
[11:07] <apw> yes the insertion of the loop should not be possible after
[11:07] <ppisati> ok
[11:11] <apw> ogasawara, heads up that kernel-wedge is borked in precise at the moment, so hold on uploading any kernels
[11:16] <ppisati> apw: it was exactly that case
[11:16] <ppisati> apw: with the patch applied, we can't create circual structures anymore
[11:16] <ppisati> "epoll_ctl_failed: Too many levels of symbolic links"
[11:17] <apw> great
[11:57] <cjwatson> apw: that kernel-wedge is uploaded, although it'll have to wait for the LP builders to be unstuck.  Did that new kernel-wedge all told cause nic-shared-modules to come back down to reasonable size and contents?
[12:03] <apw> cjwatson, the build just got lost, power outage on my builder ... stray foot
[12:03] <apw> should know soonish
[12:03] <cjwatson> stray foot> LOL
[12:10] <apw> cjwatson, annoying appendages and no mistake
[12:14] <cking> apw, looks like tangerine is stuck, can you prod it?
[12:20] <apw> cking, she is dead, need some rtg action on the power switch
[12:24] <cking> looks like udev got all locked up
[12:24] <cking> :-(
[12:24] <cking> time for lunch then ;-)
[14:02]  * ogasawara back in 20
[15:09] <sconklin> jsalisbury: you around?
[15:20] <jsalisbury> sconklin, yes
[15:22] <sconklin> jsalisbury: help me out here - I think you helped with this . . . a few weeks ago we had a bug that only showed up on systems with hybrid graphics, when Intel and Nvidia were both installed . . .
[15:22] <sconklin> And it looks to me like that might be the case with the "purple screen at boot" bug:
[15:22] <sconklin> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/880476
[15:22] <ubot2> Launchpad bug 880476 in linux "after update to kernel 3.0.0-13 ubuntu 11.10 does not start" [High,Triaged]
[15:23] <jsalisbury> sconklin, I don't recall the bug a few weeks ago, but I do recall seeing some hybrid graphics bugs comming in.
[15:23]  * jsalisbury is looking
[15:24] <sconklin> wait, I remember reverting a patch for it, let me check the git logs
[15:24] <jsalisbury> sconklin, here is one: bug 881132
[15:24] <ubot2> Launchpad bug 881132 in linux "vga_switcheroo makes system freeze" [Medium,Triaged] https://launchpad.net/bugs/881132
[15:24] <jsalisbury> sconklin, intel/radeon graphics
[15:25] <sconklin> jsalisbury: That may be a duplicate of the one I was thinking of, but same cause
[15:25] <jsalisbury> sconklin, ahh
[15:26] <sconklin> ok, that's enough of a memory kicker to probably get me what I need. It was due to an upstream patch that we reverted (In Natty I think), and I'll check and see if the same patch just landed in Oneiric
[15:26] <sconklin> jsalisbury: Thanks!
[15:26] <jsalisbury> sconklin, np, thanks for looking at this :-)
[15:27] <sconklin> jsalisbury: it rang a bell, I just couldn't do the pattern matching . . .
[15:27] <jsalisbury> sconklin, :-)
[15:28] <apw> -rw-r--r-- 1 apw apw 362368 2011-10-26 16:24 nic-shared-modules-3.1.0-2-generic-di_3.1.0-2.2~masternext201110261517_i386.udeb
[15:28] <apw> -rw-r--r-- 1 apw apw 362350 2011-10-26 16:24 nic-shared-modules-3.1.0-2-generic-pae-di_3.1.0-2.2~masternext201110261517_i386.udeb
[15:28] <apw> -rw-r--r-- 1 apw apw 308466 2011-10-26 16:24 nic-shared-modules-3.1.0-2-virtual-di_3.1.0-2.2~masternext201110261517_i386.udeb
[15:28] <apw> cjwatson, ^^ that looks more like your expectations i think ?
[15:37] <apw> ogasawara, about ?
[15:37] <ogasawara> apw: yep
[15:37] <apw> ogasawara, just checking you saw my kernel-wedge warning
[15:38] <ogasawara> apw: I did
[15:38] <apw> ogasawara, that said i believe we now have a fixed kernel-wedge in the archive
[15:38] <apw> if and when cjwatson confirms he is happy with the nic-shared-modules above we probaally want to do
[15:38] <apw> another upload to fix up the installer stuff
[15:38] <ogasawara> apw: ack.  I was hoping to upload today or tomorrow
[15:39] <cjwatson> apw: the size is definitely much better
[15:39] <cjwatson> apw: can I have dpkg -c, just to check?
[15:40] <cjwatson> and yes, kernel-wedge is fixed
[15:40] <apw> cjwatson, http://paste.ubuntu.com/719766/
[15:42] <apw> ogasawara, before you do i have two build rules fixes for you, just re-re-re-testing them now
[15:42] <cjwatson> apw: looks good
[15:42] <ogasawara> apw: cool.  feel free to push them when you're confident and then ping me.
[15:42] <cjwatson> so if you want, just reassign that bug to kernel-wedge and close it
[15:43] <apw> cjwatson, yep will do the admin on it now
[15:43] <cjwatson> great, thanks for checking that out
[15:44] <apw> cjwatson, and thanks for the quick fix on the other kernel-wedge issue
[15:45] <apw> ogasawara, ok i've pushed the two commits, i am still doing a deeep test build but don't expect issue
[15:45] <apw> ogasawara, and this way you can do some test builds in parallel :)
[15:45] <ogasawara> apw: yep, I'll kick off my test builds.  will let you know if anything breaks.
[15:46] <apw> i have one set of builds under my belt, so am expecting few issues
[15:46] <apw> ogasawara, OH you do need the latest latest latest kernel-wedge in your chroots when building
[15:46] <apw> ogasawara, so make sure they are updated
[15:46] <ogasawara> apw: ack
[15:47] <apw> ogasawara, it hink gomisa updates itself
[15:47] <ogasawara> tgardner: ^^ can we get the latest kernel-wedge in our precise chroots?
[15:47] <apw> tgardner, that reminds me.  i hand edited the update script on tangerine to add precious
[15:48] <apw> tgardner, the update for the /usr3/ubuntu/ubuntu-*
[15:48] <apw> tgardner, and that likely needs to be done on goemisa too
[15:50] <tgardner> apw, are you channeling gollum? what is precious ?
[15:51] <apw> tgardner, heh ... dammit i knew that would happen.  precise is a tooooo similar in my mind and gets swapped out
[15:51] <tgardner> ogasawara, updating now
[15:59] <tgardner> ogasawara, tangernie x86en schroots are done for precise, armel is building
[15:59] <tgardner> tangerine*
[15:59] <ogasawara> tgardner: ack
[15:59] <tgardner> ogasawara, also updated tangerine to the oneiric LTS kernel.
[16:25] <GrueMaster> Not sure that word got out, but I will be unable to test armel SRU kernels until after UDS.  Please hold all requests until then.
[16:28] <apw> bjf, ^^
[16:29] <bjf> apw, saw it, don't care, the cadence marches on
[16:34] <apw> works for me
[16:35] <apw> ogasawara, those builds worked out ok here
[16:35] <ogasawara> apw: cool, mine are just finishing up
[16:35] <apw> ogasawara, a good sign indeed.  so this is a rebase to 3.1 final ?
[16:35] <ogasawara> apw: yep
[16:39] <kees> hrm, I seem to lack access to zinc. shouldn't that still be open to non-canonical contributors?
[16:41] <tgardner> kees, I think elmo shut it down to non-canonical folks after the kernel.org debacle
[16:41] <kees> tgardner: ah. urm, that will make things a bit tricky.
[16:42] <tgardner> kees, yeah, likely. what do you need ?
[16:43] <kees> tgardner: well, I was going to rebase my various patchsets to precise.
[16:43] <tgardner> kees, you mean you can't pull? Use the git:// protocol.
[16:44] <tgardner> git://kernel.ubuntu.com/ubuntu/ubuntu-precise.git
[16:44] <kees> tgardner: I can pull fine, but I can't push
[16:44] <tgardner> kees, I guess for that you'll have to send pull requests from your kernel.org repo. 
[16:45]  * kees doesn't have one there yet
[16:45] <kees> and things are delayed due to kernel summit
[16:45] <tgardner> kees, huh, I figured you of all folks would have one. how about github ?
[16:46] <kees> tgardner: I do that. is the no-canonical thing final, or just a temp precaution?
[16:46] <kees> er, I can do ...
[16:46] <tgardner> kees, I'm not sure. I think we'd like to be as paranoid as kernel.org and restrict shell access.
[16:47] <tgardner> kees, you still coming to orlando ? I want you to sign my key.
[16:50] <kees> tgardner: I'm not, unfortunately. when will you be visiting pdx next? :)
[16:51] <tgardner> kees, dunno. maybe you could sign bjf and ogasawara. I'll get jjohansen to sign mine.
[16:51] <ogasawara> tgardner: kees has signed mine
[16:52] <tgardner> ogasawara, good, that gets you one removed from Linus
[16:52] <kees> and jj, iirc
[16:52] <ogasawara> yep
[16:52] <jjohansen> tgardner: you should also grab slangasek
[16:52] <tgardner> jjohansen, ack
[16:53] <jjohansen> tgardner: yep, I've got kees's, gregkh, trippet, bottomly, jamie sharp, and a few others
[16:54]  * slangasek feeds the web of trust into a protein-folding program and watches the carnage
[16:56] <tgardner> apw has a pretty good program for generating the web of trust relative to your key
[16:56] <tgardner> a picture of the web of trust, rather
[17:02] <apw> yeah :)
[17:02] <apw> ogasawara, we need to have a bit of a keysigning with you at UDS
[17:03] <apw> and if we can get slangasek as well we'll be looking good
[17:03] <slangasek> I think I already signed ogasawara's
[17:03] <apw> slangasek, that'll be good
[17:03] <ogasawara> apw: yep, I've got slangasek.
[17:03] <ogasawara> apw: maybe we can do some keysigning during one of our round tables
[17:04] <apw> ogasawara, or in the bar, i assume the bar will be a common location
[17:04] <slangasek> y'all going to participate in the organized KSP?
[17:04] <slangasek> not sure how organized it actually is... I guess there's a wiki page :P
[17:04] <tgardner> apw, what was that key signing program we used? caff ?
[17:04] <tgardner> yes, caff
[17:05] <slangasek> from the package signing-party
[17:05] <tgardner> slangasek, that works pretty slick
[17:05]  * slangasek nods
[17:07] <apw> tgardner, yep caff, works like a charm
[17:18] <tgardner> apw, I'm pretty sure util-linux is one of those packages that are an assumed build-dep.
[17:26] <apw> tgardner, i couldn't be sure so shoved it in for now
[17:27] <tgardner> apw, they way you muck about with fd 9 makes my head hurt. I had to go look it up.
[17:27] <apw> tgardner, heh who me ... never
[17:37] <kees> tgardner: is the precise tree on github? rebasing maybe become madness quickly if not
[17:38] <apw> kees, you can pull zinc trees over git: regardless no?
[17:38] <tgardner> kees, I started experimenting with mirroring on github at the release sprint, but I haven't wrapped it up yet.
[17:40] <tgardner> kees, why is this a problem? github is gonna be a readonly repo just like zinc.
[17:40] <kees> apw: yeah, I can fetch, but then I need to push -f a copy of precise to github so I can have my own branch to request pulls from
[17:40] <kees> apw: the trick is noticing when precise gets rebased
[17:40] <kees> anyway, I'll deal with it. :)
[17:46] <apw> kees, ahh, heh, normally leann sends out an email to say it has been uploaded at least
[17:47]  * kees nods
[17:58]  * tgardner -> lunch
[18:29] <apw> kees, hey do you know if you can configure the default retention time for ssh keys 
[18:30] <apw> (its the sort of thing you'd know i feel)
[18:31] <kees> apw: depends on your ssh-agent
[18:31] <kees> apw: if you mean the horrible thing that is it gnome-keyring now, no.
[18:32] <kees> apw: it's a seriously PITA
[18:32] <apw> kees, that is the default i assume, then yes.  it seems to have separate defaults for gpg keys and ssh keys .. but the ssh key default is more progressive than i would like
[18:32] <kees> they gutted it while trying to move to dconf, but didn't actually add support for a default.
[18:32] <apw> bah, always backwards
[18:32] <kees> \o/
[19:17] <ogasawara> apw: just fyi, I notice "UBUNTU: [Config] di -- include empty builddep fields" results in dpkg-buildpackage failing if not in a precise chroot/environment
[19:18] <tgardner> ogasawara, thats gonna make the LTS backport unhappy
[19:18] <apw> ogasawara, hrm, then i'd say drop it for now
[19:18] <ogasawara> apw: ack
[21:20] <kees> it's like magic! :) https://github.com/kees/linux/branches
[21:20] <kees> and then on monday I'll move it all to kernel.org
[21:27] <jjohansen1> kees: hehe nice
[21:28] <kees> jjohansen1: yeah, it's not ready for a pull though. I think Will is going to consolidate his patches. But I just wanted to get everything rebased at least.
[23:07] <steph7> hi do you know if acer_wmi module can freeze ubuntu at boot if blacklisted?
[23:27] <steph7> no one? :-(