Description of problem: In /usr/lib/rpm/redhat/macros there is a definition of kernel_source() macro inside the %kernel_module_package. Pay attention that %_target_cpu is delimited from kernel version by a dash sign (-) here. In directory name /usr/src/kernels/2.6.35.6-45.fc14.i686 (which is carried by kernel-devel package) an architecture is delimited fro kernel version by a point sign (.). %kernel_source macro is broken due to this mismatch. Version-Release number of selected component (if applicable): kernel-devel-2.6.35.6-45.fc14.i686.rpm redhat-rpm-config-9.1.0-5.fc14.noarch.rpm Fedora 12 and 13 are also affected.
I can take this. Note that these macros are really part of driver updates that aren't used in Fedora. Still, I might aswell fix the macros as they don't hurt either. I'll pull in the latest versions from RHEL6.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
It is still not fixed for Fedora 17.
Created attachment 621046 [details] Proposed patch to fix kernel_source macro Is this the correct patch for this issue? I only run fedora so I don't make use of this macro.
redhat-rpm-config-9.1.0-34.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/redhat-rpm-config-9.1.0-34.fc18
Package redhat-rpm-config-9.1.0-34.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 redhat-rpm-config-9.1.0-34.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-15361/redhat-rpm-config-9.1.0-34.fc18 then log in and leave karma (feedback).
This has been pushed to F18 stable.
I found that the issue wasn't yet fixed in Fedora 24, because it still uses the incorrect name when the flavor is default: + make -C /usr/src/kernels/4.7.9-200.fc24-x86_64 M=/home/jekeller/rpmbuild/BUILD/hp-i40e-2.0.2_rc4_1_g51bd5b8535bd/obj/default make: *** /usr/src/kernels/4.7.9-200.fc24-x86_64: No such file or directory. Stop. error: Bad exit status from /var/tmp/rpm-tmp.r6cVbs (%build)
The kernel macros are not really maintained in Fedora because there's no kABI. Back in 2014 I had discussions with Don and Josh (cc'd) around this, the idea roughly being for the kernel folks to take over the maintenance of this stuff, and for that purpose they were split into a separate kernel-rpm-macros which can be easily sawed off redhat-rpm-config into a new source package. I've been away from rpm business for couple of years so I'm not really up to date if something has happened on this front.
Hi, Can you provide the snippet of code in your 3rd-party driver's spec file that does the compile? I am not entirely sure which macro you are using to generate that '-'. Or better yet, point me to that rpm that I can download, rebuild and duplicate? Cheers, Don
for flavor in %flavors_to_build; do rm -rf obj/flavor cp -r source obj/$flavor make -C %{kernel_source $flavor} M=$PWD/obj/$flavor done This is to build an out-of-tree KMP package for the Intel i40e driver. You should be able to download the tarball from https://sourceforge.net/projects/e1000 and try to rpmbuild -tb <tarball> and see the issue. Note that %{kernel_source $flavor} returns the following on my Fedora 24 system when $flavor is "default" + make -C /usr/src/kernels/4.7.9-200.fc24-x86_64 M=/home/jekeller/rpmbuild/BUILD/hp-i40e-2.0.2_rc4_1_g51bd5b8535bd/obj/default See how it has "/usr/src/kernels/4.7.9-200.fc24-x86_64"? Note the "dash" between the fc24 and x86_64? The relevant line in /usr/lib/rpm/macros.d/macros.kmp file from the kernel-rpm-macros-41-2.fc24.noarch is: 48 >-------echo "%%global kernel_source() /usr/src/kernels/%kverrel-\\\$([ %%%%{1} = default ] || echo "%%%%{1}.")%_target_cpu" \ Note how it has /usr/src/kernels/%kverrel-\\\$([%%%%{1} = default ] || echo "%%%%{1}."%_target_cpu" Zoom in some more on the line: "kernels/%kverrel-" We can drop the part about if $1 = default, since this won't print anything unless flavor isn't default: so we get "kernels/%kverrel-%_target_cpu" which translates incorrectly to 4.7.9-200.fc24-x86_64 instead of 4.7.9-200.fc24.x86_64 If I change the dash just after %kverrel into a . this is fixed. The original fix changed the dot that was part of the echo "%%%%{1}-" into an echo "%%%%{1}." I hope this explains the issue, and at least for fedora 24 why we need a . here?
Oh, I realized this is for the KMP variant of our RPM build which isn't available on sourceforge currently :( I can likely get you a copy of the tarball if the above explanation isn't enough though. The spec file provided by the sourceforge tarball will build correctly because it doesn't use any of the KMP macros.
Hi Jacob, Your explaination is great and makes sense to me. I am not sure how this ever worked. But as mentioned earlier (years ago) in this thread, it was more a RHEL thing than Fedora. Regardless, can you attach your patch? I will ask the package maintainers to pull it in. Thanks! Cheers, Don
I think it worked because the format for the "source" directory probably changed at one point. It might still be correct in RHEL. We use this primarily for RHEL and SuSE, but I was just testing it on Fedora, since that's what I had around. I've attached a patch. Regards, Jake
Created attachment 1219075 [details] patch to fix kernel_source macro
Hi Jacob, Thanks for the patch! Panu, the patch looks fine to me. I don't think many users utilize that macro. Who do we poke to apply it to the package? Cheers, Don
I can apply the patch, that's not a problem. Done and build for rawhide, stable versions can be considered too. Or you could apply for commit permissions to redhat-rpm-config, but then I think the long-term point was to split the kernel stuff out of redhat-rpm-config so... but maybe that discussion belongs elsewhere :)
Hello, Just thinking aloud on Fedora support for out-of-tree kernel module packages. I don't like the %kernel_module_package macro at all. It creates a sub package of the main kmod package for no reason. Moreover the build process should not depend on the system it runs on. The output of this macro can be directly put into the .spec file of the kernel module package which removes this dependency. As such I think we should remove the %kernel_module_package completely. Thoughts welcome!
KMP is a standard, and the macros that it exports to RPMs are meant to be standardized so that you can take a spec file and use it to generate a kernel module binary RPM for a specific kernel. This is used by both RHEL and SuSE, for varying reasons. If you feel that it doesn't make sense you could remove support (which you mostly already do by extracting it to its own package). I'm not entirely understanding of the reasoning of the KMP standard, but I believe it was created so that you can use a single spec file to generate kernel module packages for differing kernels. (Since the binary depends on the kernel binary you are running, but the source (probably) doesn't)
Hi Jacob, Thanks for your points! Currently, the KMP macro behavior depends on a lot on the arguments it's used with. Which means that the result of the package depends on both the content of the .spec file and the current version of the macro. Since we can't get rid of the .spec file, it would make sense to me to just put the result of the macro to the .spec file. I believe the package can still be written to support compilation on multiple kernels if we just detect the kernel version in the .spec file. Thanks for pointing out that KMP is a standard, there's the packaging guideline for Fedora: http://rpmfusion.org/Packaging/KernelModules/Kmods2
Yes. The point is that it is already (mostly) cross distribution compatible, and it avoids having to manually do that work. Especially considering that the exact naming schemes for Kernels are not identical on each distribution, having to re-code that for these spec files would be a bit of a challenge.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
I've ran into a similar issue with the kmodtool macro which was causing lustre builds to fail. Here's a diff of the changes I made to make rpmbuild work properly. --- kmodtool 2017-12-21 16:05:19.707640431 -0200 +++ kmodtool.orig 2017-12-21 16:04:21.343437273 -0200 @@ -114,7 +114,7 @@ if [ "no" != "$kmp_nobuildreqs" ] then - echo "BuildRequires: kernel${dashvariant}-devel.%{_target_cpu} = ${verrel}" + echo "BuildRequires: kernel${dashvariant}-devel-%{_target_cpu} = ${verrel}" fi if [ "" != "$kmp_override_preamble" ]
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.