[00:17] <infinity> dannf: Seems like the sort of thing that should perhaps be static.
[00:18] <infinity> dannf: Compare to CONFIG_RTC_DRV_CMOS=y on x86
[00:18] <dannf> infinity: agreed; #1035110
[00:18] <dannf> (just asked for that)
[00:52] <infinity> hggdh: linux-lts-backport-{oneiric,natty} seem to be stalled on you?
[06:59] <ppisati> moin
[07:08] <tjaalton> my precise box died with generic-usb spamming the logs with "[242715.545184] generic-usb 0003:09EB:0131.0003: can't reset device, 0000:00:1a.0-1.4.1/input1, status -71"
[07:12] <tjaalton> running 3.2.0-29
[07:16] <smb> morning
[07:17] <smb> tjaalton, sounds like one usb device went bad (or the subsystem) 
[07:17] <tjaalton> smb: unplugging the kvm box helped, works after replug
[07:18] <smb> Unplugging the kvm box?
[07:18] <tjaalton> the usb-hub
[07:18] <tjaalton> of it
[07:18] <smb> ah
[07:18] <tjaalton> mouse and kbd attached to it directly
[07:19] <smb> yeah, I had this sometimes in the past even with real hw. usb hubs seem to sometimes just go crazy
[07:19] <tjaalton> wondering if this is the "freeze" some people are still complaining about on snb/ivb..
[07:20]  * smb realizes this kvm meant a keyboard-mouse-monitor switch and not a vm
[07:20] <tjaalton> ah, yes :)
[08:15] <ppisati> i dare you to enable -DDEBUG in arch/<$arch>/mach-<$soc>/Makefile!
[08:29] <apw> tjaalton, could you test these for me: http://people.canonical.com/~apw/lp944386-precise/
[08:37] <tjaalton> apw: on it
[08:46] <apw> cooloney_, that lxc /rootfs/ issue can we not just work around it by ln -s . rootfs in the ephemeral container setup ?
[08:48] <cooloney_> apw: it looks like only /proc fs in the container has such /rootfs/ issue, other files should be fine.
[08:49] <cooloney_> apw: i will give it a try. and from Miklos's email we might need some fixing in overlayfs.
[08:50] <apw> cooloney_, from Miklos's email it is clearly a big piece of work to fix properly
[08:50] <apw> cooloney_, and its not at all clear that overlayfs will win even
[08:50] <apw> cooloney_, and i am pretty sure we can just bodge it for our purposes as all the files have a consistant prefix
[08:50] <cooloney_> apw: yeah, ok, i will try your sugguestion soon
[08:51] <apw> yeah its not 'a fix' but it will make the issue go away i recon
[08:51] <cooloney_> right. np. 
[08:51] <cooloney_> and apw, will sbuild use multicore to build a packaging in schroot automatically? 
[08:52] <cooloney_> i'm building kdepim now. 
[08:52] <apw> cooloney_, no i think you have to ask for it
[08:53] <cooloney_> looks like it is not very fast in sbuild comparing to pure native building
[08:53] <cooloney_> apw: aha.
[09:05] <tjaalton> btw, do you keep following the upstream 3.2.x releases for precise post .1?
[09:05] <apw> tjaalton, yep we follow stable till it ends
[09:05] <tjaalton> thanks
[09:05] <tjaalton> sent a patch there but didn't end up in .27 yet
[09:05] <tjaalton> and won't, hopefully in .28 :)
[09:14] <tjaalton> apw: seems to work
[09:16] <apw> tjaalton, the link fix yes ?
[09:16] <tjaalton> right
[09:16] <tjaalton> tested by the usual mesa build with sbuild
[09:17] <apw> cooloney_, and that sbuild is slow is in keeping with expectations, slower than native, and why any testing needs to be the saem thing because comparing a native build with a buildd build is just unfair
[09:17] <apw> cooloney_, also you need to ask for parallel indeed, its something like DEB_BUILD_OPTS= something
[09:18] <apw> cooloney_, also sounds like there is a -j for sbuild itself
[09:24] <cooloney_> apw, DEB_BUILD_OPTIONs="parallel=n", right?
[09:25] <apw> i think thats what i used, but it seems sbuild -j NN will also work
[09:27] <cooloney_> apw: yeah, you're right.
[09:27] <cooloney_> -j, --jobs=n Number of jobs to run simultaneously.  Passed through to dpkg-buildpackage.
[09:27] <cooloney_> let me try again. 
[10:03] <Kano> hi, when will 3.5.1 used for quantal?
[10:04] <apw> likely in the next upload
[10:04] <Kano> estimated time?
[10:05] <apw> we just did an upload so i'd expect it to be next week early
[12:08]  * ppisati notices that NO ONE does any testing on the actual Q/omap4 kernel... nice...
[13:02] <ppisati> ahhhhhhh... :)
[13:02]  * ppisati feels much better now...
[13:08] <ppisati> i need to go out to get some stuff sorted, back in ~1hr
[13:49] <dileks> hmm, pastebinit b0rked
[13:49]  * dileks gets as URL... http://paste.ubuntu.com/
[13:59] <stgraber> dileks: hmm, it's really slow, wondering if the server isn't dead... let me check
[13:59] <stgraber> dileks: yeah, web is equally broken
[14:00] <stgraber> dileks: "lamont changed the topic of #canonical-sysadmin to: Known issues: pastebin", so it's apparently being worked on
[14:00] <dileks> stgraber: thx for feedback
[14:00] <stgraber> dileks: in the mean time, you can use "pastebinit -b http://paste.debian.net" or another one (pastebin.com, ...)
[14:01] <lamont> stgraber: mind you, I was just adding myself to the topic as a vanguard
[14:01] <dileks> pastebinit -b http://paste.debian.net .pc/applied-patches 
[14:01] <dileks> http://paste.debian.net/183046/
[14:02]  * dileks notes the workaround
[14:37]  * henrix is again having problems connecting to mumble.
[14:44] <stgraber> dileks: paste.ubuntu.com has apparently been fixed
[14:45] <dileks> stgraber: great!
[16:12] <agrester_> Hello, have a question recently Ubuntu Update is trying to push Kernel updates  3.2.0-29.46 is this a "STABLE" release, I have Nvidia Proprietary Drivers 304.32, will this cause problems or should I update to recommended?
[16:13] <apw> agrester_, we would not expect issues, you will also have your old kernel should there be issues
[16:14] <agrester_> Ok, so  3.2.0-29.46 is STABLE?  Not BETA or DEV right?
[16:16] <agrester_> Sorry I'm just paranoid and conservative about Kernel updates...
[16:24]  * ppisati -> EOW
[16:25] <agrester_> Ok, so to roll back what do I do if something goes wrong?  Do I go to the old Kernel from GRUB and then uninstall the newer Kernel from Synaptic?
[16:44]  * smb -> EOW
[16:44] <bjf> agrester_: to "roll back" you select the previous, working kernel from the grub menu
[16:45] <agrester_> ok
[16:45] <bjf> agrester_: after that boots up, if you want, you can uninstall the "bad" kernel
[16:45] <agrester_> bjf: I can do that from Synaptic yes?
[16:45] <bjf> agrester_: yes
[16:46] <agrester_> thanks
[16:52] <agrester_> Going to update now, thanks for the advice and Ubuntu team thanks for an awesome operating system :-)
[17:36]  * henrix -> EOD
[18:00] <dileks> http://git.kernel.org/?p=linux/kernel/git/mszeredi/vfs.git;a=commitdiff;h=9d91c7951a2d0be08cc56e4169c1c4385eeae549
[18:01] <dileks> apw: :-)
[18:40] <dileks> statistics/disc-usage_kernel-with-debug.txt: http://paste.ubuntu.com/1139773/
[18:40] <dileks> so for amd64 you need for a linux-3.5 kernel approx. 13.5GiB (build with deb-pkg)
[18:41] <dileks> CONFIG_DEBUG_INFO=y
[18:42] <dileks> v2: http://paste.ubuntu.com/1139781/
[20:06] <adam_g> if i'm using the quantal upstream kernels from k.u.c/~kernel-ppa, how do i get required firmware added to the corresponding initrd?
[23:48] <jimm098> Hello