[02:01] hi === klebers__ is now known as klebers [08:20] cyphermox: Socratis relayed what you said last night (if your time zone matches mine) to me. Thanks both. [08:20] I hope that secure boot, user-friendly and third-party kernel modules is not a "pick any two", but just now I can't quite wrap my head round it. [08:59] michael-vb, in general secure boot and third-party kernel modules are by definition incompatible, that is the raison d'etre of secure-boot [09:00] is there a reason you don't submit your kernel modules to the kernel, so they become not third-party? [09:00] that is waht all the other hypervisors have done [09:01] apw: to be honest I am rather confused about the raison d'être if secure boot. Matthew Garrett talked a lot about evil maid attacks, and I do not see how third party kernel modules are relevant to that at all. [09:01] michael-vb, its job is to stop random un verified binary being loaded into the kernel [09:01] loaded and run at ring0 to be more accurate [09:02] third-party modules are that very thing [09:04] Regarding submitting our kernel modules to the upstream kernel, that does not make very much sense. They are tied to a particular version of VirtualBox first, and upstream already has a hypervisor second. [09:04] And third, we just don't have the free engineer time to make them gregkh-compatible. [09:05] I suspect any of those three are blockers. [09:05] Oh how nice, a BBC micro. [09:07] then we get to the self-signing fun ... which is coming [09:07] apw: putting them in distributions might be a different matter, though it would involve some thought. [09:07] yep, might make sense, though lets hope tey don't change as quicly as some others, ugg [09:10] One of the problems is that modules from different major-ish releases are incompatible and can't really co-exist. At least not in memory. On disk they can. [09:12] Is that something Ubuntu would be potentially interested in as a solution? Shipping the modules with the kernel, but not loading them by default? [09:12] michael-vb, i am not going to say no at least [09:12] we would indeed need to think about how hard they are to maintain [09:13] and the level of support we would get for issues when updating primary kernels [09:16] apw, I know this is OT, but your kernel module has missing udev rules to make copy-paste host-guest work https://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/tree/debian/virtualbox-guest-dkms.udev [09:20] LocutusOfBorg, as in we remove them in our delta ? [09:21] or you mean when we include them in the kernel we don't include that [09:22] you should include them, otherwise copy-paste won't work because the kernel module is not accessible by normal user [09:22] (sorry I'm doing kernel stuff right now) === zyga-ubu1tu is now known as zyga-ubuntu [12:26] tseliot: did you see that I have some build fixes for nvidia with 4.12? We're going to be trying to move artful to 4.12 soon but need to get the nvidia dkms drivers (among others) fixed first. [12:58] apw, you might want to sync new vbox kernel modules, even if I don't think they differs [12:58] except for version [13:40] sforshee: I must have missed them. Where are they? [13:45] tseliot: bug 1700798 and bug 1700799 [13:45] bug 1700798 in nvidia-graphics-drivers-304 (Ubuntu) "nvidia-graphics-drivers-304 304.135-0ubuntu2 ADT test failure with linux 4.12.0-4.5" [High,Triaged] https://launchpad.net/bugs/1700798 [13:45] bug 1700799 in nvidia-graphics-drivers-340 (Ubuntu) "nvidia-graphics-drivers-340 340.102-0ubuntu4 ADT test failure with linux 4.12.0-4.5" [High,Triaged] https://launchpad.net/bugs/1700799 [13:45] sforshee: I'll have a look at them, thanks! [13:45] tseliot: ta [13:47] tseliot: For 340, there's already a patch in the graphics-drivers PPA package. It would probably be fairly easy to adapt to 304 too. [13:48] mamarley: right, I'll check out the PPA too, thanks [13:56] sforshee, hi, did you dare to check with 4.13 yet? [13:57] hi [13:59] ricotz: not explicitly, though I do see that I have a module built for 304 in a vm I'm using to test dkms updates [13:59] with 4.13 that is [14:01] sforshee, ok, I see -- 4.13 is still meant to be the target for artful? [14:01] ricotz: yep [14:01] trying 340 with 4.13 now [14:02] ok, thanks [14:02] looks like it built! [14:02] I might have actually checked that already, can't remember for sure [14:03] sounds promising, while possible runtime issues are harder to debug ;) [14:04] ricotz: yeah, the big caveat is that my patches are only compile tested [14:29] could this patch get backported to the ubuntu kernel, please? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/i915/i915_drv.c?id=ce3f7163e4ce8fd583dcb36b6ee6b81fd1b419ae [14:29] my machine freezes without this commit while playing some video games [14:30] it's already in Linus' git tree and it was also applied to 4.12.4 (stable tree) [14:30] this is the bug report: https://bugs.freedesktop.org/show_bug.cgi?id=101261 [14:30] Freedesktop bug 101261 in DRM/Intel "[G45] [drm:drm_atomic_helper_commit_cleanup_done [drm_kms_helper]] *ERROR* [CRTC:32:pipe A] flip_done timed out" [Normal,Closed: fixed] [14:31] I run both archlinux and ubuntu on this computer, archlinux will get 4.12.4 soon but I think ubuntu is on 4.10 kernel, so I was wondering if it could also be applied to ubuntu's kernel === cachio is now known as cachio_lunch === cachio_lunch is now known as cachio [16:41] dviola, we plan to release 17.10 with 4.13. the current artful (17.10) kernel in -release is a 4.11 kernel. we are working to stabilize 4.12 right now. [16:42] bjf: good, so no need to backport anything I guess? [16:43] dviola, no [16:43] ok, thank you [16:44] :) === JanC is now known as Guest48595 === JanC_ is now known as JanC