It leads to some regressions in requires generation precision, though,
as it is no longer possible to exclude requires that are satisfied
by other kmods in the package. And calling a script on each file (instead
of calling it on the whole file list at once) does not make things faster,
either (so much for "sanity and benefit").
* find-provides.ksyms: Check for "$@" as well.
* find-requires.ksyms: Likewise.
* kernel-srpm-macros.spec (Source104, Source105, Source106): New
attribute files.
(%install): Install firmware.prov and modalias.prov with executable bit;
install provided_ksyms.attr, required_ksyms.attr, and modalias.attr into
"%{buildroot}%{_fileattrsdir}".
(%files -n kernel-rpm-macros): Add provided_ksyms.attr,
required_ksyms.attr, and modalias.attr.
kmodtool: Remove "%global _use_internal_dependency_generator 0".
macros.kmp: Remove %__find_provides and %__find_requires.
* modalias.attr: New file.
* provided_ksyms.attr: Likewise.
* required_ksyms.attr: Likewise.
Resolves: #1942072Resolves: #1942563
Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
The enablement of debuginfo generation broke custom %install scripts
that perform module signing, and in an attempt to address that,
additional hooks are added that can be used for module compression,
signing, and other means of kmod processing.
* macros.kmp (redhat_kmp_has_post_hooks): New macro, set to 1.
(kernel_module_package_release): Add __brp_kmod_pre_sign_process,
__brp_kmod_sign, __brp_kmod_post_sign_process, __brp_kmod_compress,
and __brp_kmod_post_compress_process to the generated
__spec_install_post.
Resolves: #2002887
Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
This hack temporary adds executable permission for the *.ko files
during post-install stage so they are picked up by find-debuginfo.sh.
Since the intention is to avoid changing of behaviour in non-kmod
workloads, it's done by adding two additional brp-* scripts to the
__spec_install_post macro when kernel_module_package is instantiated.
* brp-kmod-restore-perms: New file.
* brp-kmod-set-exec-bit: Likewise.
* macros.kmp (%__brp_kmod_set_exec_bit, %__brp_kmod_restore_perms,
%__kmod_brps_added): New macros.
(%kernel_module_package): Rewrite __spec_install_post macro.
* redhat-rpm-config.spec (Source701, Source702): Add
brp-kmod-restore-perms and brp-kmod-set-exec-bit.
(Requires): Add find requirement for brp-kmod-set-exec-bit.
(%files): Explicitly list brp-* scripts for redhat-rpm-config and
kernel-rpm-macros packages.
Resolves: #2002887
Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
If no kernel-devel packages are installed (this is possible, for example,
during SRPM generation in an isolated environment), no output would be
generated for latest_kernel macro, which would lead to an error (since
an RPM macro can't have an empty definition). Append %nil to the input
of the "head" command to avoid this situation.
* macros.kmp (kernel_module_package): Feed additional line with %nil
to the input of head command in the latest_kernel macro definition.
Resolves: #1971748Resolves: #2002887
Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
A patch[1] to the kernel spec file changed the separator that is used
for kernel flavor designation from "." to "+", which broke kmodtool and
%kernel_module_package in multiple places. Try to accomodate it by
accepting both "+" and "." during parsing, and guessing which one should
be used for kernel osurce path generation.
PS. It looks like the analogous breakage was before, when it was changed
from "-" to ".". May be we should start support it back again as well.
[1] https://lists.fedoraproject.org/pipermail/kernel/2013-June/004262.html
* kmodtool (get_verrel, get_variant): Accept both "." and "+" as separators.
(get_variant_char, print_variant_char, print_kernel_source): New functions.
(get_filelist): Convert "+%1" in file list to $dotvariant, in addition
to ".%1" and "-%1".
(get_rpmtemplate): Determine a char that is used as a variant separator.
Use it in $dotvariant.
(usage): Mention "veriant_char" and "kernel_source" commands.
* macros.kmp (%kernel_module_package): Use "kernel_source" command in
"%kernel_source" definition when non-default variant is used; fall back
to ls-based heuristics when it is not available (for example, when a
version of kmodtool that doesn't support this command is used).
Resolves: #2002887
Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
The following packages are added:
- kernel-abi-stablelists is used by find-requires.ksym in order to
provide information regarding kABI symbol usage. It's purely
informational and optional, however.
- redhat-rpm-config and kernel-rpm-macros are added since the generted
spec files use macros from these packages.
- elfutils-libelf-devel is used during kmod build for ORC metadata
generation (used by kernel for stack unwinding).
- kmod programs are used by find-requires.ksyms and find-proivides.ksyms
for parsing *.ko files during dependency generation.
* kmodtool (get_rpm_template): Update the list of generated
BuildRequires.
* macros.kmp (%kernel_module_package_buildreqs): Update the list of
default BuildRequires.
Resolves: #2002887
Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
Apply redhat-rpm-config-9.1.0-kmod-kabi.patch from RHEL 7 branch.
Applied only changes to kmodtool and macros (now macros.kmp), as all
others are applied already. macros.kmp also had a merge conflict due to
commits f41a8a73aa6f ("Fix kernel_source macro to match the directory
that kernel sources are installed in") and d95e9bc7b618 ("Fix directory
name mismatch in kernel_source macro (#648996)") being applied already.
Commit message from the original commit:
commit 29b4b765391b8f11ae64708e86ac3f7475c62661
Author: Panu Matilainen <pmatilai@redhat.com>
Date: Tue Jul 9 09:57:29 2013 +0300
- Re-add various kABI-related bits (Jon Masters)
- Allow kmod building against z-stream kernels (Jiri Benc)
Resolves: #1971748Resolves: #2002887Resolves: #2015909
Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
No changes are being made to the individual files added here; they're
1:1 copies of the ones in redhat-rpm-config.
Note the kernel-rpm-macros version - the latest c9s build is versioned
after its parent SRPM which is redhat-rpm-config-184-1, so we need to
make this one NVR-newer to allow for clean upgrades.
The respective removals from redhat-rpm-config are tracked in #1959924.
Resolves: #1959914
