[08:08]  * apw yawns
[08:13] <smb> apw, morning
[08:13] <apw> smb, moin
[08:13]  * smb checks his clock
[08:16] <smb> apw, btw changing the workplace switch keys to super+ctrl work much better for my mind. Now maybe I should file a bug that the shortcut help screen still displays the old binding... >:-)
[08:17] <lifeless> definitely should do that
[08:19] <apw> smb, heh, you should tell didrocks cirtainly, that you had to change it to stop your fingers falling off
[08:19] <smb> meh, I probably will just get told that help screens are supposed to show the divine supposed to be configuration... Also I had the feeling that the key bindings (default) may change again after many users expressing their joy with super-shift
[08:20] <apw> you should file a bug that you changed them an its not right, that seems sensible
[08:21] <smb> Actually it was not so much the fingers, but imagination or not, it felt like that typers thing (aching things in lower arm)
[08:22] <smb> OK, maybe I really should really file it...
[08:22] <smb> ...yet another one
[08:29] <apw> smb carple tunnel, and yep a simple binding can easily cause that
[09:00] <bullgard4> Red Red offers a "Netdump" crash dump facility.  What is the nearest Ubuntu program to it?
[09:02] <apw> bullgard4 what does it do
[09:02] <apw> take crash dumps and shove them over the network somewhere ?
[09:03] <bullgard4> "Unlike traditional crash dump facilities, this facility dumps memory images to a centralized server via the network. "
[09:04] <bullgard4> "The goal of a crash dump facility is to provide fault analysis, particularly exhaustive first fault analysis (first fault analysis is when a bug can be corrected without requiring reproducing the bug), in the case of software or hardware bugs that manifest as system crashes (in Linux parlance, Oops, BUG(), or panic). "
[09:04] <apw> we have crash dumping indeed, not sure if there is any support for remote deliver of those immediatly when the dump is taken
[09:04] <apw> though that is only a matter of what you put in the crash initrd
[09:05] <bullgard4> Ah! Thank you for commenting.
[09:06] <apw> i think we did have some discussions on this sort of thing, but its more a server need than anything.  so i would suggest asking on #ubuntu-server as well, they may remember or have pointers
[09:06] <apw> smb, whats the crash package called again, i keep forgetting
[09:06] <smb> apw, crashdump?
[09:07] <apw> ahh here it is linux-crashdump
[09:07] <apw> looking for crash is a mistake it seems
[09:08] <apw> bullgard4, ^
[09:10] <smb> crash is the tool to look at the dumps
[09:10] <bullgard4> apw: Excellent! I will get acquanted with the DEB program package »linux-crashdump« (because I have infrequently kernel crashes). -- Thank you very much.
[09:11] <bullgard4> s/acquanted/acquainted/
[09:11] <ppisati> if it's just a matters of oops&c, why don't you configure syslog to send all the stuff abroad?
[09:13] <smb> ppisati, I think working crash-dump gives you the whole memory + registers of the time of the crash
[09:14] <ppisati> i see (and that being said i take swallow another coffee)
[09:15]  * smb needs a refill
[09:15] <smb> apw, btw, there seems to be kdump-tools as well, not that I would know what the differences would be...
[09:16] <apw> smb, seems linux-crashdump pulls all of those in
[09:18] <smb> apw, Hm, interesting, saw only kexec-tools, makedumpfile and some grub depends and a crash suggest...
[10:03] <_ruben> what are the chances of network being operational after a kernel crash??
[10:30] <Kano> hi
[10:32] <Kano> when you compare
[10:32] <Kano> http://packages.debian.org/wheezy/amd64/linux-headers-3.2.0-1-amd64/filelist
[10:32] <Kano> against
[10:32] <Kano> http://packages.ubuntu.com/precise/amd64/linux-headers-3.2.0-17-generic/filelist
[10:33] <Kano> you should notice that include/generated/compile.h is missing, why?
[10:34] <Kano> is it missing because of include/config/cross/compile.h ?
[10:35] <Kano> the problem is that you need that file when you use the debian nvidia-dkms package. it should be included in the u package as well
[10:46] <RAOF> Kano: Why would you use the debian nvidia-dkms package?
[10:46] <Kano> because i use the kernel on debian!
[10:47] <Kano> but thats a packageing fault, has nothing to do with the distro
[11:39] <apw> Kano, likely the layout has changed and we haven't followed it, and nothing has noticed
[11:39] <apw> Kano, can you file a bug against 'linux' and tell me the number
[11:52] <Kano> against precise?
[11:53] <apw> Kano, against linux the package, that'll go againstr precise by default yes
[11:55] <Kano> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/942569
[11:56] <ubot2`> Launchpad bug 942569 in linux "missing include/generated/compile.h" [Undecided,New]
[12:59] <Kano> apw: i see you updated the bug. hope you find the issue why the file is missing. i think you already cp include but maybe too early?
[13:00] <apw> Kano, nope compile.h is a special and doesn't get made when you ask the kernel tree for the headers 
[13:00] <apw> which frankly is rather crap
[13:02] <Kano> ah
[13:03] <Kano> maybe you see how debian did that
[13:06] <Kano> it shows similar if as /proc/version
[13:06] <Kano> just with defines
[13:06]  * tgardner reboots tangerine
[13:07] <apw> Kano, yep, its beyond me why it would be needed by this out-of-tree crap in the first place
[13:08] <Kano> in theory even an empty file fixes the compile, it just has to be there
[13:08] <tgardner> if that is the case, why not fix the OOT code ?
[13:10] <Kano> i dont know where this file is included
[13:11] <Kano> but you see it in the make.log as missing
[13:11] <Kano> what i want is that i could use the same dkms code for nv with d and u kernel
[13:11] <Kano> if i use the code for u kernel it fails with d and vice versa
[13:18] <ppisati> tgardner: hold on before uploading the M/omap4 kernel
[13:18] <tgardner> ppisati, I'm letting the stable team upload M kernels.
[13:19] <ppisati> ah right
[13:25] <tgardner> ppisati, how about P kernels ? do you need one of those ?
[13:27] <ppisati> tgardner: i'll wait for ogasawara's rebase of 3.2.8, i saw gkh released it yesterday
[13:28] <tgardner> ppisati, 3.2.8 only contains x86 cruft, e.g., FPU corruption fixes (I think)
[13:30] <ppisati> tgardner: ok, then go ahead
[13:30] <tgardner> ppisati, ack
[13:30] <ppisati> tgardner: watch out since it's complaining about a missing module
[13:30] <tgardner> ppisati, already fixed and pushed
[13:30] <ppisati> cool, thanks
[13:34] <tgardner> ppisati, the last rebase for ti-omap4 was against Ubuntu-3.2.0-16.25. perhaps you should bring ti-omap4 up to date ? there are some YAMA patches that are relevant.
[13:34]  * apw notes we don't produce reminder bugs for precise
[13:34] <ppisati> tgardner: ok, i'll do, hold on
[13:35] <tgardner> ppisati, reset you ti-omap4 HEAD to 3643ea0b470b40ca53d2f870df6e3ade07e11b5b before you start your rebase
[14:22] <herton> ppisati, about maverick kernel, the config change should fix the QA failure right?
[14:28] <ppisati> herton: yep, but i had an headless installation so i'm testing the sgx binary driver (see apw's email about it)
[14:30] <herton> ppisati, ok, once you do and everything is ok, let me know, do you want to open a new tracking bug for it and push a new branch for pulling?
[14:31] <herton> otherwise I just apply if it tested ok and I do the release process (new tracking bug etc.)
[14:32] <Kano> tgardner: dont forget to fix fglrx for 3.2.8
[14:33] <tgardner> Kano, fglrx isn't my problem. I think its alberto milone
[14:47] <hallyn> gah complete hang on vostro, no crash or sysrq response or anything (uptopdate precise)
[14:50] <jwi> tgardner: re bug 942256, you sure that those two will work without having hv_vmbus.ko on the inclusion list?
[14:50] <ubot2`> Launchpad bug 942256 in linux "HyperV modules missing from -virtual flavor" [Undecided,Fix committed] https://launchpad.net/bugs/942256
[14:51] <jwi> oh, and this closes bug 560821 as well
[14:51] <ubot2`> Launchpad bug 560821 in linux "No hyper-v modules on linux-generic-pae/virtual" [Medium,Confirmed] https://launchpad.net/bugs/560821
[14:52] <tgardner> jwi, looks like 560821 is now a duplicate
[14:52] <tgardner> of 942256
[14:55] <jwi> yeah, not sure if microsoft renamed or killed the block driver...
[14:55] <apw> tgardner, i can have a look, as i did the bits to get the right drivers into initramfs, so i should know the list
[14:56] <tgardner> jwi, I'm not sure what you'r first statement meant. are you implying that the 4 hv modules in the bug report are not sufficient ?
[14:56] <apw> tgardner, there are 5
[14:56] <apw> hv_vmbus hv_utils hv_netvsc hv_mouse hv_storvsc
[14:57] <jwi> tgardner: you only added two new files.
[14:57] <tgardner> I thought mouse got dropped
[14:57] <apw> tgardner, oh bugger have the names changed _again_ with the update to 3.4
[14:57]  * apw hates upstream sometimes
[14:59] <tgardner> apw, I think its now hid-hyperv
[15:00] <tgardner> but is it really needed for -virtual  ?
[15:10] <jwi> tgardner: duh, utils and vmbus are in the initramfs - sorry for the noise.
[15:10] <tgardner> jwi, np
[15:12] <apw> tgardner, hmmm there is a question, if you are going to use the mouse with a VM then perhaps so
[15:13] <apw> potentially it is running connected to your X display or whatever you have in hyper-v
[15:13] <tgardner> apw, its easy enough to add. lemme take care of it
[15:38] <brendand> herton, bjf - quick note to say that the Lucid kernel is probably going to be finished by Thursday, maybe Friday
[15:38] <bjf> brendand: ack
[15:38] <tgardner> apw, hid-hyperv.ko needs unknown symbol hid_allocate_device, which means more shit in the -virtual flavour. I'm thinking anyone who has X installed can also install the linux-image-extra deb to get hid-hyperv. agreed ?
[15:39] <apw> tgardner, i guess the simplest approach is to not add it, and see if anyone screams
[15:39] <brendand> bjf - point releases always put a lot of strain on our resources
[15:40]  * ogasawara back in 20
[15:45] <apw> tgardner, bah union-mounts is rearing its ugly head again, and the overlayfs maintainer remains very quiet
[15:46] <tgardner> apw, he's on LKML but won't respond to you
[15:47] <apw> tgardner, and union-mounts is 73 patches of doom
[15:48] <tgardner> apw, did I see a merge request for union-mounts ?
[15:48] <apw> tgardner, i haven't seen that yet, the patch spew looked to be an RFC to me
[15:49] <apw> but it doesn't make it any more likely we are betting the right horse
[15:49] <tgardner> ah, couldn't remember
[15:49] <apw> that with the current issues i have with semantics for inotify
[15:49] <apw> i am all a dither as to the best way forward
[15:49] <tgardner> apw, still the lxc guys whinging about overlayfs ?
[15:50] <apw> yeah, lots of packages rely on inotify, like upstart does so it does't see new jobs
[15:50] <apw> so a lot of things need fixing if inotify is not available
[15:50] <tgardner> apw, have you tried aufs lately ? I saw that it gotupdated
[15:50] <apw> tgardner, i have touch tested it though its not enabled
[15:51] <apw> tgardner, i am keeping it around in case we end up having to keep it available for these use cases
[15:51] <tgardner> apw, well, we could re-enable it and let the lxc dudes have a go at it
[15:52] <apw> phhhh, yeah we could indeed, i just didn't want to have to support both
[15:52] <tgardner> apw, though I have to wonder why all of these apps are depending on a kernel feature that is not mainline
[15:53] <tgardner> can we tell them all to just pound sand ?
[15:53] <apw>  tgardner inotify i mainline, it just doesn't work on overlayfs
[15:53] <tgardner> ah, right
[15:53] <apw> ie the apps work fine on a real root
[15:53] <tgardner> how does ecryptfs do it? can we steal that logic ?
[15:53] <apw> and i've gotten most of the way with overlays, adding support but there is a semantic
[15:53] <apw> difference on overlayfs files which bugger some use cases
[15:54] <tgardner> the 'tail -f' case ?
[15:54] <apw> specifically the tail type use case, monitoring a file for change case
[15:54] <apw> if the file gets copied, that consumer can get confused
[15:54] <apw> that and my patches are vile right now
[15:55] <apw> s/copied/copied up to the rw layer
[15:55] <tyhicks> I missed the backscroll, but I think we're talking about why inotify doesn't work on overlayfs?
[15:55] <apw> yep
[15:55] <apw> so i have some patches which in concept resolve the lack of notity
[15:56] <apw> by mirroring the underlying notifications up
[15:56] <tyhicks> interesting
[15:56] <apw> but that doesn't help with the semantic issues for copy_up against already open files
[15:57] <ppisati> herton: go ahead with M/omap4
[15:57] <herton> ppisati, ok
[15:58] <apw> tyhicks, ie you get a correct file size change notification, you re-fstat and the file is unchanged
[15:58] <apw> cause you are conncted to the wrong one
[15:59] <tyhicks> ugh
[16:00] <apw> tyhicks, now if that idiom is isolated to tail, then moving it to stat against the filename likely could fix it up
[16:00] <apw> but .. is that common or uncommon idiom
[16:00] <tyhicks> yeah
[16:01] <tyhicks> I'm glancing through the code now, but it is architected quite a bit different than eCryptfs - I don't think I'll have any great ideas here
[16:01] <apw> yeah it does passthrough of the open, you can't and don't want to do that
[16:01] <apw> and perhaps our issue is we don't want to do that either
[16:02] <apw> tyhicks, so how do you handle passing on operations to the underlying layer
[16:02] <apw> i guess you don't cause you are modifying offsets and data
[16:02]  * tgardner messes with his firewall. back in a bit.
[16:02] <tyhicks> apw: eCryptfs has duplicate inodes and dentries of everything. IIRC, overlayfs does fancy things to keep from having its own inodes, correct?
[16:02] <apw> yeah it tries to, well it has them but only when not doing open
[16:03] <tyhicks> By duplicates, I mean for every dentry and inode in the lower filesyste, eCryptfs has a corresponding inode and dentry
[16:03] <apw> and to stop having to pass on everything to the original inode
[16:03] <apw> yeah
[16:03] <apw> it is such a shame there isn't a sensbl
[16:03] <apw> wrapper for each op in the kernle, so you could just call them
[16:04] <apw> all this if (op exists) then call op, else call something else
[16:04] <apw> all being open coded, just makes life hard for slipping oneself in the chain
[16:05] <tyhicks> apw: There are wrappers for most. Are you looking for one in particular?
[16:06] <apw> more thining about the case where you mnight want to wrap any underlying one
[16:06] <apw> where you dont in advance know which ops it uses
[16:06] <apw> to act as a pass through, to maintain performance 
[16:06] <jsalisbury> **
[16:06] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[16:06] <jsalisbury> **
[16:06] <apw> whilst having a real inode
[16:11] <tyhicks> Ok, I'm seeing what you're saying now. opens are entirely passed through and overlayfs doesn't have its own file objects (for regular files) nor any file operations
[16:12] <tyhicks> apw: If you run into needed wrappers, let me know. There's a good chance eCryptfs could benefit from them too.
[16:13] <apw> tyhicks, right, and if we want open to follow copy_up one would need that indirection layer, but if it was there i'd feel i would want to wrap all the ops, and pass them down
[16:13] <apw> we shall see what the maintainer says, if he says anything
[16:13] <tyhicks> eCryptfs was the only stacked filesystem but if/when there are 2 stacked filesystems, requests for wrappers and vfs changes should carry a little more weight
[16:14] <apw> yeah, though there really should be no open coded 'defaults' like there are
[16:14] <apw> they should be in forceinlined functions if anything
[16:16] <tyhicks> When you start getting into wrappering the file operations, it gets a little hairy because you're now dealing with data and the page cache
[16:17] <apw> yeah, it is not going to work well i suspect
[16:26] <apw>  /b smb
[16:27]  * smb wonders what /b does... bash'me
[16:28] <smb> Meh, probably send message to buffer or switch to buffer 
[17:34] <apw> smb, yeah select buffer by that name
[17:57]  * apw is feeling well below par, so i am calling it a day
[19:47] <kees> tgardner: have you been skimming the seccomp_bpf threads at all? it's starting to stabilize, but the timing is really ugly what with precise beta, etc. do you have an opinion on carrying the series for precise?
[19:48] <tgardner> kees, I have not been following with any kind of attention. I've just noticed that there has been a fair amount of activity.
[19:49] <tgardner> kees, is chromium still the primary consumer ?
[19:50] <kees> tgardner: that's the trick. nothing uses it yet since it doesn't exist yet, but so far chromium and lxc (among others) are interested. RH has a libseccomp in the works, so there's lots happening, but it's not clear to me about the value of having it in precise with no consumers in precise. but if people use precise as a development platform... it'd be _really_ nice.
[19:51] <tgardner> kees, well, this kernel will be around for awhile. do you have a patch set that comfortable with ? I'd prefer something thats gonna make it into the 3.4 merge window.
[19:52] <tgardner> kees, on the other hand, we'll also be backporting subsequent kernels into the Precise user space
[19:58] <kees> tgardner: I think redpig's v12 will be the last version (or extremely close to final). v11 comments are drawing to a close and everyone seems pretty happy with it. It's not clear to be if it'll make the 3.4 window (I _really_ hope so).
[19:59] <tgardner> kees, there is still time. kernel freeze isn't until April 15
[20:00]  * kees nods
[20:00] <kees> tgardner: what would be your preferred schedule for pulling a patch series for precise?
[20:01] <tgardner> kees, likely no later then April 1. that'll give us a bit of time to verify things.
[20:01] <kees> okay, great
[20:01] <tgardner> ogasawara, I do have the date correct, right ?
[20:02] <ogasawara> tgardner, kees: kernel freeze is april 5th (not 15th)
[20:02] <tgardner> ogasawara, ah, good thing I asked :)
[20:02] <kees> hah, so... middle of march then?
[20:02] <ogasawara> tgardner, kees:  if possible, I'd maybe shoot for Beta-2 Freeze, which is March 22nd.
[20:02] <tgardner> kees, yeah, Mar 22 at the latest
[20:02] <ogasawara> kees: so yes, mid march would be ideal.
[21:32]  * cking -> EOD
[21:45]  * tgardner -> EOD
[22:14] <mahmoh> hallyn: are armhf precise containers working?  Or can you tell me what I'm doing wrong?  If I enter the container it appears to work fine but I'm trying to execute commands externally to get info. from within - http://paste.ubuntu.com/861153/
[22:15]  * mahmoh moves to ubuntu-devel with the question
[22:32] <pbuckley> mahmoh: goto ubuntu-arm
[22:32] <pbuckley> err #ubuntu-arm
[22:32] <pbuckley> youll have better luck
[22:33] <mahmoh> ack
[23:08] <skaet> ogasawara, thank you!  :D  spotted update in the release notes before I sent out the request.