[00:17] <vanhoof> apw: press and hold it
[00:17] <vanhoof> apw: brings up the how to menu
[00:20] <vanhoof> apw: http://ubuntuone.com/295An59g2Db88LurQlMtEb
[00:22] <RAOF> vanhoof: You sure you don't mean just hold <super>?
[00:23] <vanhoof> RAOF: well ill be damn'd
[00:23] <vanhoof> RAOF: lol
[00:23]  * vanhoof walks away innocently
[00:23] <vanhoof> guess i've just never held it that long
[00:23] <vanhoof> total press and hold operation
[01:21] <jono> jsalisbury, any more luck with a kernel I can test?
[01:45] <jsalisbury> jono, not test kernel as of yet.  The commits that the bisect is reporting to run have a bug in them that cause the pae kernel build to fail.  I'll let you know as soon as I get it figured out.  It should be sometime tomorrow at the latest.
[01:45] <jono> jsalisbury, no worries
[01:46] <jono> do you think you have the problem nailed down with what is causing the bug I reported?
[01:46] <jsalisbury> jono, thanks for being patient :-)
[01:46] <jono> thanks for helping jsalisbury
[01:46] <jsalisbury> jono, not yet, that is the primary purpose of the bisect, to figure out the offending commit.
[01:47] <jono> gotcha
[01:47] <jsalisbury> jono, too bad someone else isn't hitting this bug that is running amd64.  That kernel builds just fine.
[01:48] <jono> ahhh bummer
[01:48] <jsalisbury> jono, I'll take a good look at the changelog and code that is causing the build failure.  I'll make it my priority in the morning ;-)
[01:49] <jono> thanks jsalisbury!
[01:49] <jsalisbury> jono, np, should have something for you shortly.
[01:49] <jono> :-)
[05:21] <poolie> hello all
[05:21] <poolie> i think i identified the fix for bug 745112 
[05:22] <ubot2> Launchpad bug 745112 in xserver-xorg-video-intel "[arrandale] desktop is messed up with external monitors (x86_64)" [Medium,Confirmed] https://launchpad.net/bugs/745112
[05:22] <lifeless> poolie: run windows ? :P
[05:22] <lifeless> (boom tish)
[05:22] <poolie> i was wondering what to do to get a SRU starting
[05:23] <poolie> perhaps just commenting on the bug is enough
[05:23] <poolie> lifeless, ironically from stuff on the web lots of windows drivers have similar problems
[05:23] <poolie> or perhaps are randomly failing for other reasons, who can tell
[05:23] <poolie> but i bet the odds of an apple laptop driving an apple monitor are pretty good :/
[05:27] <lifeless> poolie: yeah, I'd say they are
[05:28] <RAOF> I suspect the apple firmware devs are less divorced from the apple hardware devs than for most OEMs.
[05:32]  * ogasawara yells at launchpad to load faster
[05:32] <ogasawara> poolie: that bug sounds familiar to me, did I build a test kernel for it?
[05:34] <ogasawara> poolie: I can take a better look at it in the morning
[05:39] <poolie> ogasawara, you built a kernel for a similar bug and it also fixes this one
[05:39] <poolie> but not if you boot in recovery mode, for some reason
[05:39] <poolie> no huge rush
=== bjf is now known as bjf[afk]
=== smb` is now known as smb
=== yofel_ is now known as yofel
[10:18] <Kano64> hi, did you notice that ndiswrapper -ma/-mi is broken for kernel 3.0 to 3.4?
[10:19] <Kano64> just tested a 3.2.0 kernel with updated ndiswrapper code
[10:20] <Kano64> but the userspace is broken by definition when you want autoload with alias/install directives
[10:24] <snadge> whut theres a 3.4 now? :p
[10:25] <Kano64> in utils/ndiswrapper
[10:25] <Kano64> if (`uname -r` =~ /(\d+)\.(\d+)\.(\d+)/) {
[10:25] <Kano64>     if ($2 > 4) {
[10:25] <Kano64> should be more like
[10:25] <Kano64> if (($2 > 4) | ($1 > 2)) {
[10:26] <snadge> lol the finger service has been shut down on kernel.org :P
[10:27] <snadge> ok its 3.3 rc3
[10:28] <snadge> im not unlucky enough to have to use ndiswrapper.. thats probably why it hasn't been noticed until now Kano64
[10:28] <Kano64> the 3.2 kernel does not have got a working ndiswrapper, but you only need to change the makefile in one line to update it to 1.57
[10:29] <snadge> that blows
[10:29] <Kano64> well when you replace the rest of course
[10:29] <Kano64> the makefile is from ubuntu
[10:29] <snadge> ahh okay so its not upstream yet
[10:29] <Kano64> well it is upstream
[10:30] <Kano64> but in the kernel was ubuntu/ndiswrapper
[10:30] <Kano64> and the makefile there is not from upstream
[10:31] <Kano64> http://kanotix.acritox.com/files/kernel/kanotix-kernel-acritox.bash
[10:31] <Kano64> acritox made a nice script to update your kernel 
[10:31] <Kano64> latest aufs3 + ndiswrapper
[10:31] <Kano64> please apply it
[10:31] <Kano64> aufs+ndiswrapper are tested
[10:33] <Kano64> i dont think it could be more easy for you
[10:42] <snadge> im not an ubuntu kernel maintainer :/
[10:42] <snadge> was just rebooting and stuff
=== Kano64 is now known as Kano
[11:37]  * ppisati -> back in 10
[12:08]  * cking -> back in ~60
[12:11]  * reisei back in black --__--
[12:23]  * ppisati -? goes out for some grocery
[13:11] <tgardner> apw, before I go hassle the security guys, any idea why apparmor would deny named read access to /sys/devices/system/cpu/online ? Especially when its world read accessible.
[13:24] <cking> tgardner, this is much like bug 819479 where apparmor was incorrectly stopping reads to /sys/devices/system/cpu/present
[13:24] <ubot2> Launchpad bug 819479 in firefox "Apparmor denies access to /sys/devices/system/cpu/present" [Low,Fix released] https://launchpad.net/bugs/819479
[13:25] <tgardner> cking, so this would be a bind9 profile ?
[13:25] <cking> tgardner, no idea :-(
[13:25] <cking> see also: https://lists.ubuntu.com/archives/apparmor/2011-September/001537.html - this seems to indicate /sys/.../online should be readable
[13:27] <smb> tgardner, Would sudo apparmour_status shed some light somewhere
[13:27] <smb> ?
[13:27] <tgardner> smb, sudo: apparmour_status: command not found
[13:27] <smb> tgardner, Forgive my bad spelling
[13:28] <smb> apparmor_status
[13:28] <apw> tgardner, there was an issue exposed by overlayfs in apparmour as merged
[13:29] <apw> tgardner, wherein sometimes it cannot find the pathname, jj has a fix
[13:29] <tgardner> apw, this is on an installed server. overlayfs shouldn't be in the mix
[13:29] <tgardner> smb, 3 processes have profiles defined.
[13:29] <tgardner> 3 processes are in enforce mode.
[13:29] <tgardner>    /usr/sbin/dhcpd (2188) 
[13:29] <tgardner>    /usr/sbin/named (2027) 
[13:29] <tgardner>    /usr/sbin/ntpd (2012)
[13:29] <apw> tgardner, if you could paste the error as reported by aa in dmesg at the time we should be able to tell if its the same
[13:29] <apw> tgardner, yeah it can affect any virtual filesystem depending how it makes its names
[13:29] <tgardner> apw: type=1400 audit(1328792253.861:29): apparmor="DENIED" operation="open" parent=1933 profile="/usr/sbin/named" name="/sys/devices/system/cpu/online" pid=1952 comm="named" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[13:30] <tgardner> where are profiles stored ?
[13:30] <apw> tgardner, ok so not the same issue as the name is known
[13:31] <apw> tgardner, /etc/apparmor.d i think, they are paths converted to filenames in there
[13:31] <tgardner> yep, just found them
[13:35] <tgardner> apw, updated the profile and restarted both apparmor and bind9. no errors. rebooting to make sure.
[13:38] <tgardner> apw, of course it picked this boot to fsck a 3 TB drive.
[13:39] <apw> heh
[13:39] <smb> It had to. :-P Is named only now looking at the online cpu map?
[13:40] <snadge> i think i see that message too
[13:40] <tgardner> smb, it must be spawning a number of threads based on how many CPUs are online ?
[13:40] <snadge> type=1400 audit(1328794066.931:27): apparmor="DENIED" operation="open" parent=2792 profile="/usr/lib/telepathy/mission-control-5" name="/sys/devices/system/cpu/online" pid=2796 comm="mission-control" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[13:40] <smb> tgardner, That would be my guess too. Just wondering whether we just missed that before
[13:41] <tgardner> ok, it finally booted. no error
[13:41] <snadge> is that the same thing?
[13:42] <tgardner> snadge, it is, but a different package
[13:47] <tgardner> well, I've got the apparmor source, but where in the hell is the profile for bind9 ?
[13:48] <tgardner> hmm, maybe its deliverd in bind9
[13:50] <tgardner> ah, bind9 debian/apparmor-profile
[13:51] <jdstrand> tgardner: it is 929531. this was caused by the new eglibc
[13:53] <tgardner> jdstrand, wanna patch ?
[13:53] <tgardner> jdstrand, actually, the bug is against the wrong package
[13:53] <tgardner> it should be bind9
[13:54] <jdstrand> tgardner: it should be in the apparmor base abstraction
[13:54] <jdstrand> tgardner: it is in basically everything. introduced in this glibc commit http://repo.or.cz/w/glibc.git/commitdiff/84e2a551a72c79b020694bb327e33b6d71b09b63
[13:54] <tgardner> jdstrand, uh, whatever that means. why would a library change expose this ?
[13:55] <jdstrand> tgardner: because rather than just looking at /proc/stat, it is also looking at /sys/devices/system/cpu/online
[13:55] <tgardner> ah, I see
[13:55] <jdstrand> anyhoo, I will have it fixed in a few minutes
[13:55] <jdstrand> tgardner: did you file a bug already?
[13:55] <tgardner> so its not just bind9, its everything that uses this library call
[13:55] <jdstrand> yes
[13:56] <tgardner> jdstrand, nope, was still working on tracking down root cause
[13:56] <jdstrand> which so far I have see with evince, gwibber, empathy, telepathy, etc
[13:56] <jdstrand> and now you mention bind9
[13:56] <jdstrand> ah, lets add evolution to the list :)
[13:56] <jdstrand> anyhoo, fixing
[13:56] <tgardner> jdstrand, cool, thanks for the heads up
[13:57] <jdstrand> np
[14:04] <ogasawara> smb: thanks for doing meta
[14:05] <smb> ogasawara, no problem. it was all well prepared. all I had to do was to pray I still know how to upload. :-P
=== davmor2_ is now known as davmor2
[15:24]  * cking considers frying an egg on the CPU of this old AMD laptop
=== bjf[afk] is now known as bjf
[15:29] <tgardner> cking, I think the HD gets pretty hot too
[15:29] <cking> smokin'
[15:30] <smb> Amazing the thing still survives
[15:32] <cking> so the "powersave" CPU governor should be renamed to "heatsave" as it keeps the temp down but doesn't actually really save power
[15:34] <cking> "powersave" aka "don't burn your lap" governor
[15:35]  * smb is reminded of his limitcpu script for his old tp
[15:35] <smb> Basically using ondemand but telling it "no 2GHz is not good for your health"
[15:36] <cking> it depends on where you place the laptop I suppose.
[15:36] <smb> Oh I was thinking of the laptops health more. Usually do not really usem on my lap anyway
[15:37] <smb> Especially that one was heavy still. :)
[15:44]  * ogasawara back in 20
=== bigbash is now known as zz_bigbash
[16:14] <arges> tgardner, ogasawara : looking at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/804281 . I see that ogasawara did apply this fix to the maverick backport kernel, wondering if a lucid SRU is even possible? thanks
[16:14] <ubot2> Launchpad bug 804281 in linux "Ubuntu 10.04 does not detect and install NIC driver for Intel 82579LM" [Undecided,Fix released]
[16:15] <tgardner> arges, as ogasawara pointed out in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/804281/comments/6, it doesn't seem likely.
[16:15] <ubot2> Launchpad bug 804281 in linux "Ubuntu 10.04 does not detect and install NIC driver for Intel 82579LM" [Undecided,Fix released]
[16:19] <ogasawara> arges: indeed not likely for the main Lucid distro kernel.  If you really need it in lucid and an LTS backport kernel won't suffice, you might pursue providing it in linux-backports-modules which is an elective install.
[16:21] <tgardner> ogasawara, an LBM module won't help for the netboot use case
[16:21] <arges> ogasawara, yea was just going to say this is on a lucid alternate CD install
[16:22] <ogasawara> ah, so scratch that
[16:22] <tgardner> arges, but, they could use the Lucid point release DVD
[16:22] <ogasawara> oh yah, won't that have the newer kernels?
[16:22] <arges> tgardner, ack. asking about that now
[16:23] <tgardner> ogasawara, .3 has maverick, .4 will have the rest up through Oneiric
[16:35] <manjo> tgardner, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/929636 looks like a regression 
[16:35] <ubot2> Launchpad bug 929636 in linux "[12.04] BUG: unable to handle kernel NULL pointer dereference at 00000000000000f0" [Undecided,New]
[16:37] <tgardner> manjo, it would be helpful to know from which version this has regressed
[16:38] <manjo> tgardner, I did not see it with the last kernel, and I am uptodate on a daily basis
[16:38] <tgardner> manjo, is it reliably repeatable ?
[16:38] <manjo> tgardner, yeah I am going to test it again 
[16:38] <manjo> tgardner, will let you know if I can repeat it 
[16:39] <tgardner> manjo, the correct answer is "I don't know, I'll try it repeatedly"
[16:39] <tgardner> manjo, be sure to reboot after every oops
[16:40] <manjo> yep I have already rebooted 
[16:44] <manjo> I formatted my usb around 10 times and did not happen... so I am coping large amounts of data to it now and will try to format it .. I create usb install disk around 5-6 times a day so I am bound to hit this if it is repeatable 
[16:45] <tgardner> manjo, try removing the partition table first.
[16:50] <manjo> tgardner, does not repeat ... ok will update the bug when I get some where with this 
[16:50] <tgardner> manjo, I guess its kind of racy.
[16:50] <manjo> yep that is what I think too 
[16:51] <manjo> would be nice to be able to recreate that race condition 
[16:51] <tgardner> manjo, however, its not clear that this is a recent regression. it could have been lurking for several kernel versions.
[16:51] <manjo> nothing else was connected to my USB ports except for this stick .. and the mouse 
[16:51] <manjo> on and keyboard
[16:52] <manjo> I guess while my disk was formatting I was typing on IRC... so my usb keyboard was in use .. I guess I should plug in 2 usb sticks and format them at the same time ... or some test like that 
[16:53] <manjo> I have to go take care of something else of higher priority .. I will come back to this later 
=== kamalmostafa is now known as kamal
=== arges is now known as arges_
[17:34]  * ppisati -> back in 10mins
=== dduffey is now known as dduffey_afk
=== dduffey_afk is now known as dduffey
=== dduffey is now known as dduffey_afk
=== bjf is now known as bjf[afk]
=== zz_bigbash is now known as bigbash
[18:42]  * cking kicks off 25 vlc power measurement tests, its kinda annoying hearing the same 1 minute video clip 25 times
[18:48] <tgardner> cking, earplugs ?
[18:49] <cking> i've heard it 100+ times already, so I'm now immune to it really
[18:49] <cking> it's not like when I was working on mpeg2 optimisation where I saw the same videos over and over for ~1 year
[18:50]  * pbuckley gives cking some mad respect for making the world a better place for us media freaks
=== bjf[afk] is now known as bjf
[18:51] <cking> unfortunately that was on proprietary code for set-top-boxes, but hey ho
[18:51] <pbuckley> ah.. well im sure it made someones life better ;)
[18:51] <cking> paid the bills
[18:51] <tgardner> cking, I did a sound driver once where I listened to the same KD Lang clip about a thousand times. She has such a clear voice that it was easy to hear artifacts
[18:52] <cking> tgardner, yep, now I can't watch any digital TV w/o seeing all the artifacts 
[18:53] <tgardner> cking, it sucks to be the digital literati :)
[18:53] <cking> heh
[18:54] <cking> hrm, Tuxera POSIX truncate tests take forever and a day to complete on ecryptfs 
[19:00] <tyhicks> cking: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a261a03904849c3df50bd0300efb7fb3f865137d
[19:00] <tyhicks> cking: It should be coming down the stable pipe
[19:02] <tyhicks> cking: As of 3.3-rc2, all tuxera tests should pass except for 2 rename tests, I believe
[19:03]  * tgardner -> lunch
[19:09] <cking> tyhicks, that is an accomplishment!
[19:09] <tyhicks> cking: Are you seeing a lot of failures?
[19:10] <cking> tyhicks, well, I was going to compare Lucid vs Precise vs 3.3-rcX (where X is current) and see if there any really important fixes that should be backported
[19:11] <tyhicks> Hrm, I don't know what to expect from the Lucid results
[19:11] <cking> a bit of carnage
[19:11] <tyhicks> :)
[19:13] <tyhicks> Feel free to pass the results by me for patch suggestions since I would have either wrote the fixes or committed them
[19:13]  * tyhicks might be able to remeber that far back
[19:13] <cking> well, I'd like to do the survey, collate results and compare to results with say ext3/4 as well 
[19:14] <tyhicks> Makes sense - although I don't think I remember ext3/4 ever failing one of those tests
[19:43]  * ogasawara lunch
=== dduffey_afk is now known as dduffey
[21:32] <ohsix> anyone know offhand when CLOCK_MONOTONIC stops and starts before suspend and after resume?
[21:35] <ohsix> or a more direct question, i guess; is there a flag or something to detect when a suspend has occured? there's a canary thread in rtkit that slips on suspend and demotes all the threads when it's not supposed to
=== bladernr` is now known as bladernr_afk
[22:01]  * tgardner -> EOD