kernel-livepatch-SLE16_Update_6-1-160000.1.1

- New branch for SLE16_Update_6
- commit 88a1946

- kernel-livepatch.spec: Pre-generate klp info when supported (jsc#PED-14811)
  The command "klp -v patches" shows an extra information about the currently
  loaded livepatches, namely the related rpm package name, CVE and feature
  ids. It gets the information using rpm queries. It stores the information
  under "/var/cache/livepatch" to make the next call faster. Also the cache
  is used to pass the info from a hidden snapshot to the currently running
  system on transactional systems.
  Products derived from SLE 16.1, such as UC, want to use technologies like
  systemd-sysexts. The software will be distributed using images and rpmdb
  may not be present.
  Remove the dependency on rpmdb by pre-generating the cached file during
  the livepatch package build. Store it under "/usr/share/livepatch/info"
  because packages could not contain files under "/var/cache/" directly.
  The last problem is that %%files section is defined in the generic stub
  "/usr/lib/rpm/kernel-livepatch-subpackage" provided by the package
  "kernel-livepatch-tools-devel". But the %%build and %%install phases
  are defined by "rpm/kernel-livepatch.spec" template in the master branch
  for particular livepatch sources.
  Keep the life easy by supporting all combinations of
  "kernel-livepatch.spec" template and "kernel-livepatch-tools-devel"
  packages. The solution uses the fact that the generic stub
  "kernel-livepatch-subpackage" is included into the generic template
  "kernel-livepatch.spec" after the initial metadata but before
  the %%build and %%install sections. It works the following way:
  + The generic stub "kernel-livepatch-subpackage" adds
    "/usr/share/livepatch/info/*" into %%files section only when
    the generic template "kernel-livepatch.spec" defines
    "%%with_klp_info 1" macro before the stub in included.
  + The generic "kernel-livepatch.spec" template builds and installs
    the klp info file only when "%klp_package_name" macro is defined by
    the generic "kernel-livepatch-subpackage" stub.
  Note that this solution supports any combination of the "klp" tool
  and livepatch package:
  + Older "klp" tool versions are not aware of the pre-generated info file.
    They will generate the cache using rpm queries.
  + Newer "klp" tool versions use the pre-generated info file when
    available. They are still able to generate it using rpm queries
    as a fallback.
  + SLE 16.1 will use only new "klp" tool and livepatches with
    the pre-generated info file.
- commit 78e4366

- klp_trace.h: add KLPR_TRACE_EVENT_CONDITION macro
- commit 17e9fce

- scripts/tar-up.sh: unconditionally enable s390x on SLE default
  Nowadays, s390x builds should be enabed for all SLE default kernels
  - - the versions from before the point where s390x coverage got
  added to the product have gone out of support a long time ago.
  Remove the conditional s390x enablement logic from tar-up.sh.
- commit 9bcbefb

- kernel-livepatch.spec: Replace kernel-syms with kernel-<flavor>-specific dependencies (bsc#1248108)
  The commit ead79afe7cbfae ("kernel-livepatch.spec: Update build
  dependencies for non-default flavors") broke build of livepatches
  which were built with kernel-syms-rt.
  The problem is that livepatch packages for already released kernels
  are built in exactly the same build environment as the initial livepatch.
  The BS (Build Service) installs the build environment using the given
  _buildinfo-*.xml and ignores BuildRequires. But the BuildRequires are
  later checked by rpmbuild tool. It would complain when new dependencies
  were added.
  Unfortunately, kernel-syms-rt does not exist on SLE16. This was the main
  motivation for the above mentioned commit.
  But the package kernel-syms is empty. Its only purpose is to add other
  dependencies. Replace it by opencoding the dependencies.
  Note that the kernel devel files are historically split into various
  packages, kernel-<flavor>-devel, kernel-devel-<flavor>, and
  even kernel-devel. But it is enough to require kernel-<flavor>-devel
  because it requires the other devel files on its own. This seems
  to be true back to SLE15-SP4 at minimum.
- commit 7696578

- kernel-livepatch.spec: Update build dependencies for non-default flavors
  Starting with commit 7c95ae0ac0bb ("mkspec: Exclude rt flavor from
  kernel-syms dependencies (bsc#1244337).") kernel-syms does not pull
  kernel-%variant-devel package for non-default %variant. It needs to be
  required alongside.
  Hence, add new BuildRequires for these cases (-rt flavor only at the
  time).
- commit ead79af

- Remove the support for different flavors, take 2
  There is a support for different kernel flavors from the beginning in
  our spec file. Originally, there were -default and -xen flavors.
  However, it is questionable. A live patch is built against a very
  specific kernel binary. Different flavors of the same kernel source can
  be easily different also in this respect.
  Remove it then. The build process is driven by "variant" macro deriving
  from a branch name. We can stick with that. %klp_module_package defines
  %flavor based on that. It also keeps %flavors_to_build definition for
  older releases without this change.
- commit b9cd481

- Revert "Remove the support for different flavors"
  The removal of flavors in spec file needs to go hand in hand with rpm
  macros update unfortunately. It is a work in progress so revert the spec
  file changes for now so that current builds do not fail.
  This reverts commit 6254bb4ada3a5af59ea00493698f92edc0b4c9a2.
- commit 0ae16b9

- scripts/tar-up.sh: Handle SLFO-Main_Update_0 package
  SLFO-Main_Update_0 (and possibly its -RT variant) will be used by QA for
  testing live patching in SLFO:Main project before a product like SLE16
  is branched off.
  Handle it in our scripts so that everything works properly.
- commit b8cab65

- Remove the support for different flavors
  There is a support for different kernel flavors from the beginning in
  our spec file. Originally, there were -default and -xen flavors.
  However, it is questionable. A live patch is built against a very
  specific kernel binary. Different flavors of the same kernel source can
  be easily different also in this respect.
  Remove it then. The build process is driven by "variant" macro deriving
  from a branch name. We can stick with that.
- commit 6254bb4