[12:10] <tseliot> rtg: hi, I recovered all the commits from my original branch but now master-next fails to build (not my fault). Shall I base my branche on master?
[12:10] <tseliot> *branch
[12:11] <rtg> depends on what is failing to compile I guess. Is it in your pile or mine ?
[12:11] <tseliot> rtg: drivers/scsi/qla2xxx/tcm_qla2xxx.c:466:12: error: 'TARGET_SCF_USE_CPUID' undeclared (first use in this function)
[12:11] <tseliot> that's not mine
[12:11] <rtg> tseliot, ok, thats mine. base on master-next and I'll figure it out.
[12:12] <apw> man i really wanted that pile to get its own upload
[12:12] <tseliot> rtg: ok, but I'm going to use master for testing, just to be sure
[12:13] <rtg> tseliot, thats fine. the stuff already on master-next is completely unrelated
[12:13] <tseliot> rtg: ok, good
[12:24] <rtg> tseliot, fixed the compile failure
[12:59] <tseliot> rtg: great, I'll rebase on that, thanks!
[13:00] <rtg> tseither one is fine
[13:00] <rtg> tseliot, either branch is fine
[13:01] <tseliot> rtg: and by either you mean master-next and...?
[13:01] <rtg> tseliot, master or master-next
[13:02] <tseliot> rtg: ok, I just wanted to be sure
[13:06] <tseliot> master builds. Building master-next now
[13:10] <rtg> tseliot, I'm happy with master. just send the updated pull request.
[13:28] <tseliot> rtg: a pull request of my master-based branch into master or into master-next?
[13:29] <rtg> tseliot, doesn't matter. whatever you currently have is fine
[13:29] <tseliot> ok
[13:30] <rtg> there isn't enough difference between master and master-next at this point to mamke a difference
[13:30] <tseliot> true
[13:45] <tseliot> rtg: ok, pull request sent. The kernel works well here
[13:45] <rtg> tseliot, ack
[14:03] <jdstrand_> jsalisbury: hey, fyi my comments in bug #1547619. I can summarize though, the new xenial kernel in the archive has the bug, and the url you gave in you last comment has kernels I previously tested
[14:12] <tseliot> rtg: here is the upstream pull request that includes the only non-upstream patch in my branch https://lists.freedesktop.org/archives/dri-devel/2016-March/102119.html (just in case)
[14:13] <rtg> tseliot, ack, thanks
[14:30] <jsalisbury> jdstrand, ack, let met make sure I uploaded the right kernel
[14:34] <jsalisbury> jdstrand, I must have copied it to the wrong place.  I'm just going to rebuild the kernel, so we're confident it's the right one.
[14:36] <jdstrand> thanks
[15:02] <jsalisbury> jdstrand, I rebuilt that kernel and re-posted it: http://kernel.ubuntu.com/~jsalisbury/lp1547619
[15:15] <Hell-Razor> hey fellas... anybody good with patching kernels? I have been trying to get this patch working for an hour probably with no luck. i downloaded it from sorceforge (reiser4) trying to patch 4.4
[15:33] <jdstrand> jsalisbury: thanks
[18:14] <jtaylor> hi, you updated the megaraid driver in the 4.4 kernel right?
[18:15] <jtaylor> bug 1544679
[18:15] <jtaylor> because my machine is not booting anymore due to some issue with it
[18:16] <jtaylor> someone interested in debugging? then I could go get a picture of the error ._.
[20:18] <apw> jtaylor, yep, if its blowing up, anything you can get ... file a new bug against linux and reference the update above and include the piccy
[20:18] <apw> jtaylor, and ... let us know the bug# here
[20:25] <jtaylor> apw: do you know if there have been updates to this driver since 4.2?
[20:25] <jtaylor> I haven't tested the 4.4 before the thing mentioned in the changelog
[20:25] <jtaylor> but 4.2 works
[20:25] <jtaylor> I'll file a bug
[20:25] <apw> jtaylor, i do not, i just recall that bug going past ...
[20:26] <apw> yes please, and note hte bug# here please, so we can get some attnetion on it, so we can determine if it is that update
[20:26] <apw> we should be able to offer you an old 4.4 build from just before it
[20:27] <jtaylor> apw: I have been using the recently uploaded lts-xenial build
[20:27] <jtaylor> thats ok to file a bug from?
[20:27] <apw> sure, its the same bits inside
[20:28] <jtaylor> file against linux or the lts source package?
[20:28] <apw> file it against the lts if you are running that, in case it is an interaction with userspace that triggers it
[20:28] <apw> and i can add a task for linux too as it is more likley general and affects both
[20:29] <jtaylor> the root is on the raid so it shouldn't be using userspace before it fails
[20:29] <jtaylor> ok starting to file it now
[20:43] <jtaylor> apw: bug 1552903
[20:43] <jtaylor> ups should have probably shrunk the image a little in size ..
[20:47] <apw> jtaylor, thats fine, could you also grab a dmesg from the latest kernel which worked for you
[20:47] <apw> and indicate that in the bug
[20:47] <jtaylor> sure
[20:51] <jtaylor> apw: done
[20:55] <apw> jtaylor, passed it on to rtg as he did the update ... thanks for reporting
[20:56] <jtaylor> thanks, I'll can probably do some testing tomorrow or next week in evenings
[21:03] <rtg> jtaylor, I'll pass on your bug to the Canonical project manager that deals with these guys. The update request was in bug #1544679.
[23:18] <cristian_c> jsalisbury: hi