[09:54] <henrix> Hauke: yeah, you're right: that struct shouldn't have been included in that backport.  anyway, that seems harmless and probably not worth the trouble fixing it
[13:56] <leitao> ogasawara, hi there. 
[13:56] <leitao> ogasawara, is it possible to backport https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1439562 to 14.04.2 in SRU?
[13:58] <leitao> arges, ^
[13:58] <arges> leitao: looking
[13:58] <ogasawara> leitao: heh, was just about to throw that at arges too :)
[13:58] <arges> leitao: so when you say 14.04.2, you mean the 3.16 kernel right?
[13:59] <leitao> arges, right.
[13:59] <arges> leitao: sure i'll target that and assign myself
[13:59] <leitao> arges, cool. This is going to be a big help.
[13:59] <leitao> Do you have an ETA on when we would have that for 3.16 kernel?
[14:00] <mnaser> i might have a 3.16 SRU soon too :X -- https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1458045 -- this is close to being solved / patched upstream
[14:01] <arges> leitao: next sru cycle so probably jul 04
[14:01] <leitao> arges, good
[14:02] <arges> mnaser: that's an interesting bug, i'll put it on my radar
[14:03] <mnaser> arges: right now there's a proposed fix by someone .. http://lkml.iu.edu/hypermail/linux/kernel/1505.3/01029.html and http://lkml.iu.edu/hypermail/linux/kernel/1505.3/01030.html
[14:04] <arges> mnaser: oh excellent, make sure that link is in the bug. Once that fix lands in linus' tree we can backport it into affected Ubuntu kernels. Thanks for debugging this!
[14:08] <mnaser> no problem arges, ill post it there
[14:09] <mnaser> arges: updated and i'll update the bug once it (and hopefully if) it lands
[14:10] <arges> mnaser: great. thanks
[15:01] <arges> leitao: hey i see https://github.com/open-power/linux/commits/ubuntu/utopic , are there specific commits in that branch that are needed for the ubuntu 3.16 kernel?
[15:02] <leitao>  arges: I will check later, quite busy atm
[15:02] <arges> leitao: i'll post in the bug
[15:02] <arges> thanks
[15:02] <leitao> arges, good
[15:06] <jsalisbury> **
[15:06] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:06] <jsalisbury> **
[15:07] <cristian_c> jsalisbury, hi
[15:08] <jsalisbury> cristian_c, hello
[15:09] <cristian_c> jsalisbury, are there any news about build of that kernel you told me?
[15:10] <jsalisbury> cristian_c, not yet.  I hope to have some time to investigate further this week.
[15:11] <cristian_c> ok
[15:18] <genkgo> jsalisbury: thank you for the build you finished the other day (the one that should solve the problems with the hyperv platform). however, the patches are not working in our case. since we do not even see the slightest change, i wonder it might be the build that does not contain the required patches. is there anyway i confirm the build does actually contain the patches?
[15:19] <jsalisbury> genkgo, can you post the output of uname-a, that way I can confirm you are running the correct kernel?  I'll then review my git repo for that kernel to confirm all the patches are there.
[15:20] <genkgo> jsalisbury: Linux VPS-Web-Produc2-Genkgo 3.19.0-18-generic #18 SMP Wed May 20 17:57:26 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[15:21] <infinity> That was actually not the most helpful indicator. ;)
[15:21] <jsalisbury> genkgo, hmm, that doesn't seem right.  The test for the kernel version: "3.19.0-18-generic" should have something like "~lp1445195" on the end of it
[15:21] <infinity> cat /proc/version might be more helpful.
[15:22] <genkgo> Linux version 3.19.0-18-generic (root@gloin) (gcc version 4.9.2 (Ubuntu 4.9.2-10ubuntu13) ) #18 SMP Wed May 20 17:57:26 UTC 2015
[15:22] <jsalisbury> although it was built on gloin
[15:22] <genkgo> jsalisbury: i used these http://kernel.ubuntu.com/~jsalisbury/lp1445195/vivid/
[15:22] <genkgo> they say -0.18
[15:23] <genkgo> without the dot of course
[15:23] <apw> it is an unoffiial build at least, as its not got -Ubuntu in there, as you would expect coming from gloin
[15:23] <apw> not sure how the heck that is root@gloin, some fakeroot leakage perhaps
[15:24] <infinity> apw: He built with "fakeroot debian/rules foo", so yeah, it's all "as root".
[15:24] <infinity> apw: As opposed to a proper dpkg build, which does it all as $user, except for the deb-building bits.
[15:24] <apw> ahh a lack of binary-foo as yourself first then
[15:25] <apw> performance of that sucks if you don't remember to do the binary-foo ... sigh
[15:25] <genkgo> infinity: but does it matter regarding my testing?
[15:25] <jsalisbury> genkgo, so it does look like the right kernel.  I just didn't add the ~lp1445195 onto it
[15:25] <jsalisbury> genkgo, I'll confirm it has all the commits that were requested in the bug.
[15:25] <infinity> apw: No real harm in fakerooting the whole thing, except that it's WAAAAAY slower, especially on a multicore box like gloin.
[15:25] <apw> so slow, ugg
[15:26] <infinity> (Cause sysvipc sucketh)
[15:27] <genkgo> jsalisbury: thank you for looking up, i'll wait for that then
[15:27] <infinity> apw: Just remember, any time you feel the need to curse how awful sysvipc (especially in the fakeroot context) is, Hurd doesn't have sysvipc, and fakeroot uses a TCP IPC imlpementation there.
[15:27] <jsalisbury> genkgo, np, I'll let you know
[15:27] <infinity> apw: That performs exactly as well as you'd expect. :/
[15:28] <apw> infinity, just don't, i may remeber if you say it again
[15:28] <infinity> apw: TCP IPC!
[15:28] <infinity> apw: TCP IPC!
[15:28] <apw> swine
[16:01] <jsalisbury> genkgo, I just updated the bug.  Your test kernel is missing one commit.  I added an explanation in the bug.  I'll have another test kernel for you shortly.
[16:01] <genkgo> aight, wonderful :)
[16:05] <genkgo> jsalisbury: we do not have a confirmation however that someone actually used the new builds succesfully
[16:06] <genkgo> whether it is vivid, utopic or trusty
[16:30] <cyking> jsalisbury, hi! any luck with the bisect for my bug?
[16:33] <awreece> Has someone here used the userstacktrace funtionality in ftrace before?
[16:46] <jsalisbury> cyking, the next test kernel for your bisect failed, so I need to figure out why.  That can happen ofter with bisects because your going back to a point in time in the mainline tree.  At that time there can be other bugs that caused a kernel build failure.  So the trick is to find what fixed the build fail.  Then apply it before any kernel builds that fail because of it.
[16:55] <jsalisbury> ##    
[16:55] <jsalisbury> ## Kernel team meeting in 5 minutes
[16:55] <jsalisbury> ##
[16:55] <cyking> jsalisbury, its too bad "they" don't save every build for each git commit. Disk space isn't that expensive anymore. ^_^ 
[17:00] <jsalisbury> ##  
[17:00] <jsalisbury> ## Meeting starting now 
[17:00] <jsalisbury> ##  
[18:05] <cyking> jsalisbury, i'm running into a problem where i cant use lxc containers on my system when using .13.0-031300-generic.  would you have a suggestion to which 3.13 kernel i could use in the mean time that would let my nic fuction and lxc containers work ?   reference: https://github.com/lxc/lxc/issues/472
[18:06] <cyking> *when using 3.13.0-031300-generic.
[18:10] <cyking> never mind: changing the config to lxc.aa_allow_incomplete = 1  seems to work.  sorry
[19:28] <jsalisbury> genkgo, I have a new vivid test kernel here: http://kernel.ubuntu.com/~jsalisbury/lp1445195/vivid/
[19:28] <genkgo> jsalisbury: wonderful, will work on this tomorrow (dutch time), will let you know my results
[19:29] <jsalisbury> genkgo, great.  Thanks for testing!
[19:48] <genkgo> jsalisbury: just installed everything. it was without trouble, now i will start backups tomorrow.
[19:48] <genkgo> jsalisbury: only had to --ignore-depends=binutils just like before
[19:51] <jsalisbury> genkgo, ack.  thanks again.
[20:02] <awreece> what diagnostic tool do people here use for digging into performance issues? Is it exclusively perf, or some ftrace or systemtap, etc?