[00:13] <kees> any reason we build the ARM kernels with CONFIG_OABI_COMPAT?
[00:16] <bjf> kees, can't think of any reason. we don't notmally turn on anything with EXPERIMENTAL in the description. rtg would be the one to ask however
[00:17] <bjf> kees, file a bug?
[00:17] <bjf> kees, or mail to the mailing list
[00:18] <kees> bjf: okay, cool
[00:58] <leb> can anyone help with this
[00:58] <leb> https://gist.github.com/tildeleb/7329005
[01:06] <infinity> leb: Not really a kernel question, but you want sys/inotify.h, not linux/inotify.h... You should never include linux/ headers from userspace.
[01:07] <leb> I know it's no a kernel question
[01:07] <leb> sorry about that
[01:07] <leb> but other channels didn't have much of a clue
[01:07] <netrunner__> hello everybody
[01:08] <leb> trying to compile an older inotifyd so this is not my code
[01:08] <netrunner__> i need support due to a fail at the new kernels
[01:09] <netrunner__> http://imagebin.org/275897
[01:09] <netrunner__> http://imagebin.org/275900
[01:09] <netrunner__> output of dmesg:
[01:09] <netrunner__> http://paste.ubuntu.com/6367846/
[01:10] <netrunner__> does anyone have a idea?
[01:10] <netrunner__> some more information:
[01:10] <netrunner__> the 3.2.1-52-generic-pae kernel is the last one who works
[01:10] <leb> infinity thanks
[01:11] <netrunner__> the newer one dont work
[01:11] <netrunner__> cant boot
[01:11] <leb> changing from linix/ to sys/ solved the issue
[01:11] <netrunner__> how i do that??
[01:11] <netrunner__> i am not an expert
[01:11] <leb> muchas gracias
[01:12] <netrunner__> jep, thanks in advance for help :-)
[01:12] <netrunner__> or is this message for another guy?
[01:13] <netrunner__> anybody here who can help me?
[01:31] <bjf> netrunner__, what i suggest is you boot the working kernel and file a bug
[01:31] <bjf> netrunner__, what timezone are you in?
[01:33] <bjf> netrunner__, once you file the bug and we take a look at it you are going to get asked to test some kernels
[01:33] <netrunner__> MEZ
[01:34] <netrunner__> ok, i have already boot the working kernel
[01:34] <netrunner__> how can i file a bug
[01:34] <bjf> kinda late for you :-) (or early depending on how you look at it)
[01:34] <netrunner__> ?
[01:35] <bjf> netrunner__, from a terminal type: "ubuntu-bug linux"
[01:38] <netrunner__> it is not possible because i have a kubuntu ditro
[01:38] <netrunner__> distro
[01:39] <bjf> netrunner__, https://bugs.launchpad.net/ubuntu/+source/linux/+filebug
[01:50] <netrunner__> http://paste.ubuntu.com/6368039/
[01:51] <netrunner__> that is the output of "ubuntu-bug linux
[01:51] <netrunner__> i have netrunner - a kubuntu distro
[01:51] <netrunner__> should i really register at: https://bugs.launchpad.net/ubuntu/+source/linux/+filebug?
[01:53] <bjf> netrunner__, yes, we need the bug filed
[01:53] <netrunner__> ok i will sign up
[02:10] <netrunner__> ok, how can i file this bug now?
[02:10] <bjf> netrunner__, got to the url i posted ^
[02:13] <netrunner__> jep, there is a wizard, but i dont know the cause of the problem
[02:13] <netrunner__> and i dont know the package the wizard is asking for
[02:14] <bjf> netrunner__, the package is already set to "linux" just fill out the summary and further information (what the probelm is and how to reproduce) then "submit bug report" at the bottom
[02:20] <netrunner__> Can i also add pictures to the bug report?
[09:28]  * apw yawns
[10:47] <reisei> hi, all! I'm compiling kernel for omap4, but got the error: objdump: /lib/libc.so.6: File format not recognized
[10:47] <reisei> dpkg-shlibdeps: error: objdump gave error exit status 1 How can I fix it?
[11:34] <reisei> Any advice will be appreciated
[11:54] <ppisati> robher: didn't you leave some debug printk around in your mac address learning patch?
[11:54] <ppisati> robher: printk("unlearned addr %pM\n", addr);
[11:54] <ppisati> robher: printk("learned addr %pM\n", src_addr);
[12:04] <apw> reisei, compiling in what environment, that sounds like you are running a forign binary
[12:05] <reisei> apw: already found that was some kind of ASCII file. Just copy the library itself and it work.
[12:12] <reisei> apw: arm-linux-gnueabi- lost some of the files...
[12:19] <ppisati> robher: and one last thing that it's a bit counterintuitive, why do you learn the src_addr on the xmit path? since we are on the way out, shouldn't we learn the dst_addr or maybe the src_addr on receive?
[12:19]  * ppisati should put some printk and check by himself...
[12:30] <apw> https://wiki.ubuntu.com/ARM64/FoundationModel
[12:55] <athira> i am new to contributing to ubuntu launchpad.i reported a bug in secure-delete package and i have attached and submitted the patch.i didnt set a reviewer for my patch.can anyone tell me how to set a reviewer?
[12:56] <robher> ppisati: yes, those printks should be removed. We need to learn the src addr so that received pkts with that dst addr are not dropped. We'll never get the pkt on the receive side if the addr is not known.
[13:37] <apw> athira, you would normally subscribe the ubuntu-sru team if it is for a stable release, or for devel just ask the patch-pilot on #ubuntu-devel
[15:24] <apw> hallyn_, hey .. we have reports of networking issues inside lxc containers on 3.12 kernels
[15:24] <apw> hallyn_, mean anything to you ?
[15:24] <hallyn_> apw: well there's the known offloading of checksums for veth as of 3.11 or 3.10...
[15:25] <hallyn_> ubuntu software as of saucy should be updatd to handle it
[15:25] <hallyn_> but what sort of issues are yous eeing?
[15:27] <smb> apw, hallyn_ maybe we should find out whether the setup has openvswitch for the container involved
[15:29] <ogasawara> ah, wasn't that one of the busted dkms packages for 3.12?
[15:30] <smb> one of the complicated cases where features moved to the in-kernel module and caused a lot of head scrating as of how to cope with the dkms module (especially in P userspace)
[15:30] <smb> *scratching
[15:31]  * hallyn_ is surprised at the # issues in 3.12
[15:45] <ppisati> back in 20
[15:50] <smb> apw, Hm, just my few cents here... maybe you are already further in looking but from the console logs its hard to say whether network went away completely or "just" some fail in the resolver
[15:53] <apw> smb, i think the implecation of the further testing is that it works outside the lxc and not inside
[15:55] <apw> hallyn_, so in this case we have a report of an lxc container where the 'host' can talk to archive.u.c, and the lxc container processes cannot
[15:55] <apw> hallyn_, this is from a test case which works with a downgraded kernel
[15:56] <apw> hallyn_, do we know of any configuration changes between 3.11 and 3.12 in that area, i assume more is available there namespace wise
[15:57] <hallyn_> apw: i can't think of anything...
[15:57] <hallyn_> apw: is there an lp bug for this?
[16:00] <apw> hallyn_, not as yet
[16:01] <apw> hallyn_, is this something i can easily (or you) test in isolation 
[16:01] <apw> that network isolation is working on 3.12, do we have any tests ?
[16:03] <hallyn_> apw: well lp:~serge-hallyn/+junk/lxc-tests has some.  but i've been experimeinting with containers on 3.12 for the last few days with no issue
[16:03] <hallyn_> haven't upgraded kernel in 2 days probably
[16:03] <apw> hallyn_, ok that is a good data point, what kernel would you have tested ours or something of your own
[16:03] <apw> bug #1248590
[16:03] <ubot2> Launchpad bug 1248590 in linux (Ubuntu) "on qa-radeon-7750, containers lose network connectivity" [Critical,Confirmed] https://launchpad.net/bugs/1248590
[16:03] <apw> hallyn_, thats the one
[16:04] <hallyn_> apw: I'm on 3.12.0-1-generic #3-Ubuntu SMP Tue Oct 29 18:41:32 right now
[16:05] <apw> hallyn_, ok thats the archive one ...
[16:06] <hallyn_> apw: alas the dmesg in that bug is from a run where they haven't tried a container
[16:08] <apw> hallyn_, they say it is an autopilot test, and it goes wrong in the 'update yourself' phase thereof
[16:10] <hallyn_> apw: ok, but - the containers, are they newly created each time, or are they using stale ones?
[16:10] <hallyn_> if they are using older contaienrs (or debian) then they can get the old dnsmasq which won't work with newer kernel
[16:10] <apw> hallyn_, do you know the otto tool at all, its that one
[16:11] <hallyn_> i don't
[16:11] <hallyn_> also, 3.11 is not old enough to make a difference with that
[16:12] <hallyn_> i'm readig the linked incident log right now
[20:57] <kees> whee, it only took me 5 months to get this backported and tested, but I've sent a Precise ARM seccomp-bpf patch to the list now.
[23:11] <hallyn_> apw: good news, reversing the CLONE_PARENT restriction which broke lxc-attach seems to be acceptable upstraem.
[23:16]  * hallyn_ out for the day