Description of problem: I'm unable to compile most thirdparty kernel modules due to an empty /usr/src/kernels/3.7.1-2.fc18.x86_64/include/linux/version.h file Version-Release number of selected component (if applicable): 3.7.1-2.fc18 How reproducible: Every compile fails Steps to Reproduce: Try and compile nvidia (310.19) or virtualbox (4.2.4) with kernel 3.7.1-2.fc18 Actual results: Expected results: I expect it to compile Additional info: deleting /usr/src/kernels/3.7.1-2.fc18.x86_64/include/linux/version.h fixes the compile issue. surely this file is obsolete now as it's been replaced by /usr/src/kernels/3.7.1-2.fc18.x86_64/include/generated/uapi/linux/version.h
fixed in git.
*** Bug 892138 has been marked as a duplicate of this bug. ***
*** Bug 892974 has been marked as a duplicate of this bug. ***
*** Bug 893039 has been marked as a duplicate of this bug. ***
kernel-3.7.1-5.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/kernel-3.7.1-5.fc18
Package kernel-3.7.1-5.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.7.1-5.fc18' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-0518/kernel-3.7.1-5.fc18 then log in and leave karma (feedback).
*** Bug 894490 has been marked as a duplicate of this bug. ***
well the zero-byte file is now away, nice would be the symlink directly dunno what upstream thinks here by moving things around ln -s /usr/src/kernels/3.7.2-201.fc18.x86_64/include/generated/uapi/linux/version.h /usr/src/kernels/3.7.2-201.fc18.x86_64/include/linux/version.h
kernel-3.7.2-201.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/kernel-3.7.2-201.fc18
kernel-3.7.2-201.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
I'm running 3.7.2-201.fc18.x86_64, and version.h is still missing from the kernel source tree (/usr/src/kernels/3.7.2-201.fc18.x86_64/include/linux/). I had to link version.h from the kernel-headers (/usr/include/linux/version.h) as Comment #8, before being able to recompile VMware modules. Any intention to fix this behavior?
correct, it would be fine to have this symlink in the package but now it is better than before where te location existed as zero-byte file leading any onlie-instructions for set the symlink to fail
(In reply to comment #11) > (/usr/include/linux/version.h) as Comment #8, before being able to recompile > VMware modules. Try filing a bug report against vmware as it's their issue now, they need to add 3.7 kernel support. > Any intention to fix this behavior? Should should ask the vmware developers.
Leigh, so you mean that version.h was moved in linux 3.7 ? I haven't heard of it, but if this is the case, then yyeah, vmware (and all others) should update their stuff.
(In reply to comment #14) > Leigh, so you mean that version.h was moved in linux 3.7 ? Yes. Sorry this is the best link I could find for the headers files move https://lkml.org/lkml/2012/7/20/419 > I haven't heard of it, but if this is the case, then yyeah, vmware (and all > others) should update their stuff.
*** Bug 896539 has been marked as a duplicate of this bug. ***
I would think that if this has changed in the 3.7.x series that companies like AMD and VMWare would already have fixed it. However, I just downloaded the installer for the AMD ATI Driver (dated 1-9-2013) and it's still looking in the wrong location. In my case, they are looking in /lib/modules/3.7.2-201.fc18.x86_64/build/include/linux/version.h not /usr/include/linux/version.h directly. Wouldn't it be easier to just create the symlink when the headers and kernel source are installed? I realize that it's a workaround--not a fix, and that the "fix" falls on the various projects/applications. Have a great day:) Patrick.
technically this would be easy - but i gave up to hope that opensource-developers come up with pragmatic solutions because in context of software not in the repos they are infected by the NIH-syndrome (Not Invented Here)