[08:10] <davmor2> Laney: you can keep your suggestions of testing to yourself, can you image what would happen if I broke the kernel that would block everything ;)
[08:13] <davmor2> Laney: but on a serious note what are the steps is there a bug I have a kvm setup that allows uefi and secureboot I can have a play with it next week
[08:14] <Laney> hi davmor2 
[08:15] <Laney> you're supposed to be prompted to disable SB if you try to install a dkms module and have it on
[08:15] <Laney> that started with xenial
[08:15] <Laney> we were wondering if that prompting happens correctly in all cases
[08:15] <Laney> for example if you upgrade from wily
[08:17] <davmor2> Laney: it did with nvidia and broadcom, the intel and amd microcodes don't trigger dkms and amd didn't from trusty to xenial because the driver is downgraded to the free one till the binary version lands
[08:18] <Laney> background is somehow I ended up without wifi because of that
[08:39] <apw> davmor2, i thought that the amd was going native from 16.04 out
[08:42] <davmor2> apw: so there are 2 parts still it's just the rewritten binary wasn't ready for 16.04
[08:44] <apw> davmor2, you make me sad
[08:44] <davmor2> apw: amdgpu and amdgpu-pro iirc
[08:45] <apw> so we will get a new dkms package sometime "later" ?
[08:45] <davmor2> apw: as I understand it everything that can be free is free in the amdgpu driver but there are some bits that can't be and will be in the pro bit
[08:46] <davmor2> apw: yeap but the gfx guys can fill you in more I'm sure
[08:46] <apw> davmor2, thanks for the background 
[08:58] <jtaylor> why is it so difficult to get bug 1248289 fixed? its been more than 2 years with a patch and its imo very important functionality
[08:58] <ubot5> bug 1248289 in linux (Ubuntu Yakkety) "Missing libunwind support in perf" [Medium,Triaged] https://launchpad.net/bugs/1248289
[09:01] <apw> jtaylor, there are any number of reasons, things are more likely to get in when they are clear an unambigious, and yet more so if someone pulls the patches needed together, tests them and submits them to our mailing list directly
[09:02] <apw> jtaylor, we have a lot of bugs out there and finding nuggets like this with fixes is non-trivial
[09:02] <apw> jtaylor, that said, didn't we apply that just recently ?
[09:02] <jtaylor> yes the second time you said you did but the buildlog says no
[09:04] <apw> jtaylor, confusing, i know i reviewed the proposed patch and sent the submitter to check that in the test builds
[09:07] <jtaylor> apw: just checked the source, no binutils-dev in b-d also nothing in changelog
[09:07] <jtaylor> apw: did it maybe not make it into the proposed kernel?
[09:09] <apw> jtaylor, something did ... the moral equivalent to the patch in comment #17 to my reading
[09:09] <apw> jtaylor, so it looks like rtg got the wrong end of your stick here
[09:09] <jtaylor> yes that seemed to have worked according to the buildlog
[09:10] <jtaylor> but its still missing binututils-dev
[09:10] <apw> jtaylor, which is utterly why he originally asked you to submit the patch ... as you understand the issue at hand and the mess that this bug has become
[09:11] <apw> jtaylor, so yes the anwser to your question is, yes we applied the patch in that bug
[09:11] <apw> jtaylor, unfortuanatly that patch only has half the story, and i can't find another patch in there
[09:12] <apw> jtaylor, so i think we cna forgive his getting it wrong
[09:12] <apw> jtaylor, are you saying all we need is to add binutils-dev to the build-deps too ?
[09:12] <apw> jtaylor, and if i do that and spin you a test kerenl, can you test perf from it for me to confirm it is enough for your purposes ?
[09:15] <jtaylor> apw: adding binutils-dev should be enough
[09:15] <jtaylor> apw: the build log is enough, but I can also test it
[09:15] <jtaylor> apw: which debian folder do you modify for the kernel? debian or debian.master?
[09:15] <apw> jtaylor, debian.master
[09:16] <jtaylor> apw: the log also says its missing libperl-dev but I don't know what that is actually used by, missing gtk and numa is likely less important
[09:16] <apw> jtaylor, d/r clean rebuilds the debian/* ones
[09:17] <apw> jtaylor, i am hopefully building the tools with that enabled now, and will get you a log
[09:18] <jtaylor> apw: the interesting part is when building tools/perf, "Auto-detecting system features:"
[09:21] <apw> ...                     libunwind: [ on  ]
[09:21] <apw> ...            libdw-dwarf-unwind: [ on  ]
[09:21] <apw> those two ?
[09:23] <apw> jtaylor, no that isn't enough as the built one has that
[09:24] <apw> ...                        libbfd: [ on  ]
[09:24] <apw> that a
[09:24] <jtaylor> apw: libbfd is the one
[09:24] <apw> jtaylor, that appears to have changed, is that what we are trying to achieve here ?
[09:24] <jtaylor> libunwind was missing which is fixed by the makefile patch
[09:24] <jtaylor> in current proposed
[09:24] <jtaylor> apw: yes that is what we want
[09:25] <apw> jtaylor, and indeed is what the bug claims to want, no wonder this went wrong ...
[09:25] <jtaylor> apw: in the old log it said, add libbfd-dev to gain symbol demangling
[09:26] <jtaylor> apw: yes the original bug report was reporting this but it turned out there was a second issue that broke it, missing libunwind due to lzma
[09:26] <jtaylor> apw: I should have summarized the issue ... the bug is a little confusing
[09:26] <apw> i've put a clarification in the bottom
[09:27] <apw> do you want to test the perf this makes ?
[09:27] <apw> or are you happy that is sufficient for this bug
[09:28] <jtaylor> apw: I can test it if you send me the binaries
[09:28] <apw> jtaylor, 32 or 64 bit ?
[09:28] <jtaylor> but I'm confident it will work now so I can also wait for the update
[09:28] <jtaylor> 64 bit
[09:29] <apw> jtaylor, i'd rather not be SRUing a fourth fix for lack of testing
[09:37] <cking> testing is paramount to ensuring quality
[09:37] <cking> *ensure
[09:38] <jtaylor> sure just send me the files, I can test trusty and xenial
[09:39] <jtaylor> fwiw you can also test it by running perf top next to e.g. gcc compiling stuff
[09:39] <jtaylor> if you have demangled names it works :)
[10:14] <apw> jtaylor, ok http://people.canonical.com/~apw/lp1248289-xenial/
[10:14] <apw> jtaylor, should have the bits you need to test, i presume you can run that perf against the current installed kernel if you try :)
[10:15] <apw> hard enough
[10:15] <apw> without installing the kernel i mean
[10:53] <jtaylor> apw: it works :D
[11:28] <apw> jtaylor, ok suplemental patch submitted, i expect it'll be a little while grinding unless we get a respin
=== Guest65617 is now known as alvesadrian
=== alvesadrian is now known as adrian-
=== adrian- is now known as adrian1
=== adrian1 is now known as adrian121
=== adrian121 is now known as alvesadrian
[11:55] <jtaylor> apw: its not really urgent, people have been dealing with it since 13.04, a few weeks more won't matter :)
[11:57] <apw> jtaylor, fair point indeed
=== Guest67500 is now known as adrian
[14:37] <tseliot> rtg: nvidia 361 should be fixed now (I've just uploaded the fix). I'll look into the other two in a bit
[14:37] <rtg> tseliot, thanks
[14:38] <mamarley> tseliot: The graphics-drivers PPA has a 340 package that is patched for 4.6.  I have been testing it for several days on two boxes and have had no issues.
[14:39] <tseliot> mamarley: right, I'll review that one then . Is there a patch for 304 too?
[14:40] <mamarley> tseliot: Not directly, but the 340 one will probably be pretty close to what you need for 304 too.
[14:40] <tseliot> mamarley: ok, thanks
[15:02] <manjo> apw, will you be around 20mts from now? I really need your help .. 
=== Guest59880 is now known as adrian
[18:59] <gerow> Hi folks, qq wrt to <https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1582864> (which jsalisbury is handling) about how long should I expect to wait until the fix is released in a new package?
[18:59] <ubot5> Launchpad bug 1582864 in linux (Ubuntu Wily) "use after free of BOS in usb_reset_and_verify_device" [Medium,In progress]
[19:00] <gerow> I don't need an exact date, just trying to figure out if I'll need to build a fork for my users before that happens or not
[19:06] <jsalisbury> gerow, the current sru cycle is 27-Apr through 17-Jun.  With a targeted release to -updates on June 20th.  
[19:08] <gerow> jsalisbury: thanks sounds like a yes that I'll need a fork :)
[19:08] <gerow> thanks for the update
[19:08] <jsalisbury> gerow, yes, that might be best, until the fix is releaed via updates.  
[19:09] <gerow> Is the SRU cadence documented somewhere? So I don't have to bother you all next time I need to know?
[19:11] <jsalisbury> gerow, it's can change at times.  The most up to date schedule is published in the weekly newsletter.  The newsletter is emailed to the kernel-team mailing list, and can be seen here:
[19:11] <jsalisbury> https://wiki.ubuntu.com/KernelTeam/Newsletter/
[19:11] <gerow> great, thanks again
[19:11] <jsalisbury> np
[19:16] <TJ-> Why would "Failed to connect to Mir: Failed to connect to server socket: No such file or directory" be reported when executing an X application from the terminal, launched by another (sudo) user, with e.g. "sudo /usr/bin/env DISPLAY=:0 XAUTHORITY=/home/<user>/.Xauthority xclock" - do we need to copy more of the target users' native environment? any in particular? presumably this is some kind of
[19:16] <TJ-> fall-back if an X session isn't located?
[19:30] <TJ-> oh drat! wrong channel!
[19:43] <gerow> jsalisbury: another question about that bug :), is there any process for potentially speeding that up? We'd like to avoid a fork if at all possible and we're seeing this bug hit about 200 of our hosts per day.
[19:45] <jsalisbury> gerow, I'm not sure off hand, but I can look into it.
[19:52] <gerow> jsalisbury: cool, I'd appreciate that
[20:45] <pkern> jsalisbury: That bug was hitting us pretty nastily in terms of USB3 stability, i.e. scrambling for a few months tracking this down while users kept complaining that they can't get their work done because the memory corruption propagated down to process hangs. \:
[20:46] <pkern> jsalisbury: So thanks for the consideration. :-)
=== JanC is now known as Guest59129
=== JanC_ is now known as JanC