Hi, I have a bug report that can't build virtualbox kmods for kernels on rawhide
Larry Finger for opensuse wrote:
Yes, it does not work for kernel 4.11. The "#ifndef" will eventually be replaced by "#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 13, 0)", but that will not work until kernel 4.13-rc1 is released. You asked about 4.13-rc0, but that entity does not exist here. If your kernel Makefile does indeed have 4.13, then use the kernel version test.
So the main question is kernel Makefile does indeed have 4.13 ?
Thanks,
On Fri, Jul 14, 2017 at 7:46 AM, Sérgio Basto sergio@serjux.com wrote:
Hi, I have a bug report that can't build virtualbox kmods for kernels on rawhide
Larry Finger for opensuse wrote:
Yes, it does not work for kernel 4.11. The "#ifndef" will eventually be replaced by "#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 13, 0)", but that will not work until kernel 4.13-rc1 is released. You asked about 4.13-rc0, but that entity does not exist here. If your kernel Makefile does indeed have 4.13, then use the kernel version test.
So the main question is kernel Makefile does indeed have 4.13 ?
No, and it won't until upstream releases 4.13-rc1. Merge window kernels are called 4.12+ until that point. The RPM versioning in Fedora is a construct to reflect that we are working on what will be the 4.13 code base.
josh
On Fri, 2017-07-14 at 08:03 -0400, Josh Boyer wrote:
On Fri, Jul 14, 2017 at 7:46 AM, Sérgio Basto sergio@serjux.com wrote:
Hi, I have a bug report that can't build virtualbox kmods for kernels on rawhide
Larry Finger for opensuse wrote:
Yes, it does not work for kernel 4.11. The "#ifndef" will eventually be replaced by "#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 13, 0)", but that will not work until kernel 4.13-rc1 is released. You asked about 4.13-rc0, but that entity does not exist here. If your kernel Makefile does indeed have 4.13, then use the kernel version test.
So the main question is kernel Makefile does indeed have 4.13 ?
No, and it won't until upstream releases 4.13-rc1. Merge window kernels are called 4.12+ until that point. The RPM versioning in Fedora is a construct to reflect that we are working on what will be the 4.13 code base.
As I completely understand that we test it , I ask if is it possible change kernel Makefile to reflect the new release , seems to me more correct ... .
Anyway, hopefully, these merge windows are short and we already have 4.13-rc1 released since yesterday.
Thanks,
On Mon, Jul 17, 2017 at 8:40 AM, Sérgio Basto sergio@serjux.com wrote:
On Fri, 2017-07-14 at 08:03 -0400, Josh Boyer wrote:
On Fri, Jul 14, 2017 at 7:46 AM, Sérgio Basto sergio@serjux.com wrote:
Hi, I have a bug report that can't build virtualbox kmods for kernels on rawhide
Larry Finger for opensuse wrote:
Yes, it does not work for kernel 4.11. The "#ifndef" will eventually be replaced by "#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 13, 0)", but that will not work until kernel 4.13-rc1 is released. You asked about 4.13-rc0, but that entity does not exist here. If your kernel Makefile does indeed have 4.13, then use the kernel version test.
So the main question is kernel Makefile does indeed have 4.13 ?
No, and it won't until upstream releases 4.13-rc1. Merge window kernels are called 4.12+ until that point. The RPM versioning in Fedora is a construct to reflect that we are working on what will be the 4.13 code base.
As I completely understand that we test it , I ask if is it possible change kernel Makefile to reflect the new release , seems to me more correct ... .
I'd recommend against it. It's an invented version that would only live for 2 weeks at a time and be a patch that needs to be applied. Upstream already expressed dislike for our invented 2.6.40 that we carried for a while because it causes confusion the other way too (e.g. "what is 2.6.40?? that's not a real version").
Instead, I'd recommend not building anything external against any merge window kernel. That is the time of maximal code churn and given that upstream doesn't provide a stable kernel ABI/API anyway, it seems to be the worst possible time to try and build something. Just wait for -rc1.
josh
On Mon, 2017-07-17 at 08:51 -0400, Josh Boyer wrote:
On Mon, Jul 17, 2017 at 8:40 AM, Sérgio Basto sergio@serjux.com wrote:
On Fri, 2017-07-14 at 08:03 -0400, Josh Boyer wrote:
On Fri, Jul 14, 2017 at 7:46 AM, Sérgio Basto sergio@serjux.com wrote:
Hi, I have a bug report that can't build virtualbox kmods for kernels on rawhide
Larry Finger for opensuse wrote:
Yes, it does not work for kernel 4.11. The "#ifndef" will eventually be replaced by "#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 13, 0)", but that will not work until kernel 4.13-rc1 is released. You asked about 4.13-rc0, but that entity does not exist here. If your kernel Makefile does indeed have 4.13, then use the kernel version test.
So the main question is kernel Makefile does indeed have 4.13 ?
No, and it won't until upstream releases 4.13-rc1. Merge window kernels are called 4.12+ until that point. The RPM versioning in Fedora is a construct to reflect that we are working on what will be the 4.13 code base.
As I completely understand that we test it , I ask if is it possible change kernel Makefile to reflect the new release , seems to me more correct ... .
I'd recommend against it. It's an invented version that would only live for 2 weeks at a time and be a patch that needs to be applied. Upstream already expressed dislike for our invented 2.6.40 that we carried for a while because it causes confusion the other way too (e.g. "what is 2.6.40?? that's not a real version").
Instead, I'd recommend not building anything external against any merge window kernel. That is the time of maximal code churn and given that upstream doesn't provide a stable kernel ABI/API anyway, it seems to be the worst possible time to try and build something. Just wait for -rc1.
OK , JFTR [1] was not my fault :)
[1] https://bugzilla.rpmfusion.org/show_bug.cgi?id=4594
josh _______________________________________________ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-leave@lists.fedoraproject.org
kernel@lists.fedoraproject.org