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}"
    fi

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

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"
    fi
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.

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.

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.

Removed the fix from the current package. Closing as NOTABUG.