We never use the stable_rc mechanism. It just adds clutter to the spec
and in the rare case where we grab patches from a stable RC we've just
applied them via ApplyPatch. Get rid of it.
The buildid mechanism is still used by a nubmer of people, but it's
unnecessarily complicated in the spec. We don't need to do all the
manipulations that are current done just to allow people to easily
mark their builds as different. Just leave the commented out
definition and include it in pkg_release.
headers_check is run twice when building the kernel rpms.
CONFIG_HEADERS_CHECK is already set to "y" in config-generic. But there
are also a few lines in kernel.spec where headers_check is invoked again.
Also
grep -q exist hdrwarnings.txt
will never match as errors aren't redirected to hdrwarnings.txt
Set CONFIG_BOOTPARAM_HOTPLUG_CPU0 to 'y'. Currently, to disable CPU0,
the "boot" cpu, one must specify cpu0_hotplug as a kernel parameter.
Setting this config variable to 1 enables it by default.
I've tested this on systems where it was expected to work and it seems to
function properly.
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
We haven't set using_upstream_branch to 1 since we started using git.
Almost 7 years is a long time to carry something around we aren't using.
Drop the upstream_branch stuff.
This reverts commit b9ba7a75aff520e7b402dc1b61e165a3db44ae9c.
Reverts of reverts. For fun. If we do a kernel-doc package, it might
be better to be in a different SRPM.
(On Dec 17, 2013)
10:35 < jwb> ajax, drm-i915-dp-stfu.patch
10:36 < jwb> ajax, is that something upstreamable?
10:37 <@ajax> it's probably worth dropping at this point
10:37 <@ajax> if it's still as noisy as it was then it's probably worth
investigating
This still applies through some confounding patch magic, but the entries were
added to the upstream kernel with commits ddf6ce45a7b and d11c78e97e1d46a93e.
Over 2 years ago. Sigh.
