Bug 648996 - %kernel_source macro is broken
Summary: %kernel_source macro is broken
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: redhat-rpm-config
Version: 26
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jon Masters
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-11-02 17:22 UTC by Matwey V. Kornilov
Modified: 2018-05-29 12:11 UTC (History)
10 users (show)

Fixed In Version: redhat-rpm-config-56-1.fc26
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1061375 (view as bug list)
Environment:
Last Closed: 2018-05-29 12:11:04 UTC
Type: ---


Attachments (Terms of Use)
Proposed patch to fix kernel_source macro (613 bytes, patch)
2012-10-03 17:36 UTC, Toshio Ernie Kuratomi
no flags Details | Diff
patch to fix kernel_source macro (541 bytes, patch)
2016-11-09 21:29 UTC, Jacob Keller
no flags Details | Diff

Description Matwey V. Kornilov 2010-11-02 17:22:12 UTC
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.

Comment 1 Jon Masters 2010-11-16 07:49:10 UTC
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.

Comment 2 Fedora End Of Life 2012-08-16 21:56:13 UTC
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

Comment 3 Matwey V. Kornilov 2012-10-03 16:03:26 UTC
It is still not fixed for Fedora 17.

Comment 4 Toshio Ernie Kuratomi 2012-10-03 17:36:30 UTC
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.

Comment 5 Fedora Update System 2012-10-04 01:06:43 UTC
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

Comment 6 Fedora Update System 2012-10-04 17:48:26 UTC
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).

Comment 7 Toshio Ernie Kuratomi 2012-11-09 11:50:24 UTC
This has been pushed to F18 stable.

Comment 8 Jacob Keller 2016-11-08 01:51:50 UTC
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)

Comment 9 Panu Matilainen 2016-11-08 10:43:21 UTC
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.

Comment 10 Don Zickus 2016-11-08 17:32:19 UTC
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

Comment 11 Jacob Keller 2016-11-08 18:04:46 UTC
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?

Comment 12 Jacob Keller 2016-11-08 18:06:04 UTC
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.

Comment 13 Don Zickus 2016-11-09 16:35:34 UTC
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

Comment 14 Jacob Keller 2016-11-09 21:28:35 UTC
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

Comment 15 Jacob Keller 2016-11-09 21:29:49 UTC
Created attachment 1219075 [details]
patch to fix kernel_source macro

Comment 16 Don Zickus 2016-11-10 14:44:49 UTC
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

Comment 17 Panu Matilainen 2016-11-11 07:38:07 UTC
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 :)

Comment 19 Stanislav Kozina 2016-11-16 14:41:28 UTC
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!

Comment 20 Jacob Keller 2016-11-16 22:22:27 UTC
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)

Comment 21 Stanislav Kozina 2016-11-18 13:57:55 UTC
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

Comment 22 Jacob Keller 2016-11-18 16:26:54 UTC
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.

Comment 23 Fedora End Of Life 2017-02-28 09:29:16 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Comment 24 Michael Watters 2017-12-21 18:07:18 UTC
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" ]

Comment 25 Fedora End Of Life 2018-05-03 08:28:17 UTC
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.

Comment 26 Fedora End Of Life 2018-05-29 12:11:04 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.