Bug 1271199 - bad variable usage in kmodtool usage
bad variable usage in kmodtool usage
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: redhat-rpm-config (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Florian Festi
Karel Srot
: EasyFix
Depends On:
Blocks: 1289025
  Show dependency treegraph
Reported: 2015-10-13 07:23 EDT by Levente Farkas
Modified: 2016-07-27 02:14 EDT (History)
1 user (show)

See Also:
Fixed In Version: redhat-rpm-config-9.1.0-69.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-07-26 07:34:00 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Levente Farkas 2015-10-13 07:23:10 EDT
in redhat-rpm-config-9.1.0-kmod-kabi.patch there is a bug in line 375 there is a bug:
rpm -ql kmod-${kmod_name}${dashvariant}-%{kmod_version}-%{kmod_release}.$(arch) | grep '\.ko$' > /var/run/rpm-kmod-${kmod_name}${dashvariant}-modules

the variables
should have to be 

since it's not run in the spec file itself but during the post install phase. so otherwise you've got such an error:

error: ^%{kmod_version}$: regcomp failed: Invalid content of \{\}
error: %preun(kmod-stretch-7.14.0-1.el7.viduxos.x86_64) scriptlet failed, exit status 1
error: kmod-stretch-7.14.0-1.el7.viduxos.x86_64: erase failed
Comment 5 Karel Srot 2016-07-08 06:46:20 EDT
I am not skilled in building kernel modules but to my understanding the output of kmodtool is supposed to be part of the global spec file. Assuming that, I would expect that %{kmod_version} and %{kmod_release} macros would be defined earlier in that spec file.

If this is true, then kmod-testmodule-%{kmod_version}-%{kmod_release} is properly expanded during the package build.

There is also additional code in the kmodtool:

    if [ ! -z "$kmod_version" ]; then
        echo "Version: %{kmod_version}"

    if [ ! -z "$kmod_release" ]; then
        echo "Release: %{kmod_release}"

This code also implies that those two macros are expected to be defined earlier within the global spec file.

The proposed fix replaces these macros with shell variables but expects that these variables are defined outside of the script. But from the kmodtool script I assume that such variables are supposed to work only as switches (on/off) for adding the respective SPEC content, not to store particular value.
Similarly to
    if [ -z "$kmod_provides_group" ]; then
        echo "Group:            System Environment/Kernel"
where kmod_provides_group is also not defined in the script at all.

So to summarize it, I believe that this report should be closed as NOTABUG and we should rollback the applied patch.
Comment 6 Levente Farkas 2016-07-09 04:48:19 EDT
not it's a bug! in the spec file it should have to be % but it's a kmodtool shell script which inherit variables from the spec file so it'd have to be $. just as used a few lines above where it's wrong.

but anyway it's very easy to try! just let's make a try and you'll see it.
if you like i can send a spec file.
Comment 7 Karel Srot 2016-07-09 15:45:05 EDT
Hi Levente,

these two macros are supposed to be defined earlier in the SPEC file via %kernel_module_package macro call (or you need to define them explicitly) and therefore they are properly expanded during the SPEC file processing. Actually, I just found bug 653170 from 2011 which explains that in #c8.
Comment 8 Florian Festi 2016-07-26 07:34:00 EDT
Removed the fix from the current package. Closing as NOTABUG.

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