This enables the 32-bit EFI entry point on 64-bit kernels, so hardware
like Baytrail devices with 32-bit firmware on a 64-bit cpu can boot the
64-bit kernel.
Signed-off-by: Peter Jones <pjones@redhat.com>
The %package foo and %description foo bits should always match. If you use
-n for one, use it for the other, and vice versa.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
When doing a variant build, you want kernel-variant-headers to Obsoletes:
and Provides: kernel-headers, so that it can upgrade/replace
kernel-headers. Otherwise, attempting to install kernel-variant-headers
leads to rpm spewing file conflicts with kernel-headers, if installed.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
There was some discontinuity between the Requires and Provides with
respect to variant builds. They have to match, or you wind up with variant
builds that can't install w/o forcing them to ignore dependencies.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
This was resulting in a variant build with dependencies like so:
error: Failed dependencies:
kernel--vanilla-core-uname-r = ...
The variant already has a - at the start of it, so the always-there one
should be after variant and variant will provide the one between kernel
and itself.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Yeah, I shouldn't be committing things to the Fedora kernel tree when I
haven't done so in years, and its after 2am on a Saturday night. I promise
I haven't been drinking though...
Signed-off-by: Jarod Wilson <jarod@redhat.com>
If you try rebuilding with a %variant set, you'll hit:
error: line 2026: Package does not exist: %post -n kernel-tools
In the %post defs, we had '%post -n kernel-tools', while the package was
named simply '%package tools', which for the base kernel build, meant they
worked out to the same thing, but if doing say a kernel-vanilla build, you
had kernel-vanilla-tools and kernel-tools mismatching. This fixes the
inconsistency.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
