[14:58] <LocutusOfBorg> sforshee, maybe lets talk here
[15:14] <sforshee> LocutusOfBorg: ok
[15:15] <sforshee> it's less work for us to use the in-kernel drivers as they should always be compatible with whatever kernel version we're working with
[15:16] <sforshee> but as I said, if they are currently missing features it's not too much trouble to keep importing the drivers from the dkms package
[15:17] <LocutusOfBorg> in my opinion it depends on how many features you want to give users
[15:17] <LocutusOfBorg> having vbox in seeds is a trouble for me in freeze
[15:18] <LocutusOfBorg> and meh, as long as the basic screen works, people are happy without the guest stuff, specially for live session
[15:20] <sforshee> right, my position would be to keep importing them into the kernel until the in-kernel drivers provide the necessary functionality
[15:26] <LocutusOfBorg> as you wish, keeping importing them was not so trivial, due to me forgetting to prod you and vice-versa
[15:28] <sforshee> LocutusOfBorg: ok, so what exactly would be missing if we switch to the in-kernel drivers? Shared folders, anything else?
[15:28] <sforshee> if the in-kernel drivers currently do provide sufficient functionality then I'm fine with switching to them
[15:29] <sforshee> so really I'm just asking you to convince me ;-)
[15:29] <LocutusOfBorg> vboxguest vboxsf vboxvideo are provided by the guest-dkms package
[15:30] <LocutusOfBorg> probably shared clipboard and sf are the missing bits
[15:31] <LocutusOfBorg> we have also the 3d functionality in vbox-guest-x11, so you have 3d accelerated guest
[15:31] <LocutusOfBorg> but you need an additional package for it
[15:33] <sforshee> so if it is only sf and clipboard ... for installer I think we could do without those
[15:35] <sforshee> then why don't we give the in-kernel drivers a try, we'll see how it goes
[15:50] <LocutusOfBorg> sforshee, I think with bionic we are already using the in-tree kernel driver?
[15:50] <sforshee> for vboxvideo yes. It does not have the vboxguest driver, that was added in 4.16
[15:50] <LocutusOfBorg> at least we spoke wrt enabling for 18.04 or 18.10 can't remember now
[15:51] <LocutusOfBorg> wow I wasn't aware
[15:53] <sforshee> that's why I was asking, if we use the in-kernel vboxguest driver we lose the sf driver
[15:53] <LocutusOfBorg> also using the vboxvideo you lose it
[15:53] <LocutusOfBorg> so, before you were losing 2 drivers, now you lose only one
[15:54] <LocutusOfBorg> s/o/oo/g :)
[15:54] <sforshee> we can use the in-kernel vboxvideo driver with the other two from vbox-guest
[15:55] <sforshee> but vboxsf depends on exports from vboxguest which are not exported by the in-kernel driver
[15:56] <LocutusOfBorg> oh... this is a big problem then
[16:09] <LocutusOfBorg> anyhow, lots of time before 18.10 to see complains or revert decision
[16:09] <LocutusOfBorg> FWIW we have the safe fallback called "install vbox-guest* and live happy"
[16:09] <LocutusOfBorg> e.g. your vbox video passthroug 3d might not work  at all
[16:10] <LocutusOfBorg> because you don't have mesa overrided llibraries
[16:10] <LocutusOfBorg> so how can it work?
[16:10] <LocutusOfBorg> you also don't set rules to dkms created devices
[16:10] <LocutusOfBorg> look here https://sources.debian.org/src/virtualbox/5.2.12-dfsg-2/debian/virtualbox-guest-utils.init/#L62
[18:44] <Simon-> how do I download the source for 4.4.0-127.153 (on xenial)?
[18:45] <Simon-> https://packages.ubuntu.com/xenial/linux-image-4.4.0-127-generic just gives me links to 128 and 127 isn't available at that location
[18:45] <Simon-> there's a bug that has severely broken SCTP and I want to identify exactly what has changed
[18:46] <tyhicks> Simon-: https://launchpad.net/ubuntu/+source/linux/4.4.0-127.153
[18:47] <tyhicks> Simon-: 'dget https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/linux/4.4.0-127.153/linux_4.4.0-127.153.dsc' would also likely work
[18:47] <tyhicks> (I've never used dget to pull down a kernel source package but use it regularly for other packages)
[18:49] <Simon-> thanks
[19:01] <Simon-> I think someone has failed to consider that AF_INET6 SCTP sockets can have AF_INET address bound to them :|
[19:01] <Simon-> sctp_inet6_cmp_addr used to be able to compare two AF_INET addresses but now they will just never match
[19:18] <Simon-> how would I get d625329b06e46bd20baf9ee40847d11982569204 applied to xenial's kernel quickly?
[19:21] <Simon-> actually I think that may not correctly compare the port :|
[19:27] <Simon-> the port happens to be in the same place in both sockaddrs, so it will work
[19:37] <Simon-> it's proposed for stable but it doesn't look like it's in there yet: https://lkml.org/lkml/2018/5/18/439
[19:47] <Simon-> it is in fact already in 4.16.10, https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.16.10
[19:51] <Simon-> however, this is 4.4... the fix is in 4.4.133, https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.133
[22:43] <jeremy31> jsalisbury Thanks for your time spent on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1764645