refactor(kernel): refactor as local spec

[rlmenge]

Summary

This PR starts the Azure Linux kernel local-spec migration

What Changed

1. Maintained local-spec workflow for kernel packaging was preserved and tightened.
2. Removed stale/unused inherited inputs and variant machinery that are no longer part of Azure Linux packaging paths.
3. Removed stale build toggles that were no longer meaningful in the current spec path.
4. Rewrote the kernel component README to be Azure Linux-focused.
5. Cleaned rpminspect configuration to match currently produced packages/patches (and removed stale inherited exceptions).
6. Preserved required operational sources (for example module-signing and logrotate-related sources) where they are still functionally needed.
7. Retained changelog/release continuity and corrected historical release/changelog sequencing where needed.

Why

The previous spec and auxiliary files still contained inherited distro-specific paths and exceptions for variants we no longer ship. This increased maintenance overhead and made review/validation noisy.

This PR reduces divergence and dead paths while keeping behavior aligned with the actual Azure Linux kernel build outputs.

Notes for Reviewers

• Review commit-by-commit; each commit is intended to stand on its own.
• Most changes are removal of unused inherited paths plus alignment of generated outputs and metadata.
• README changes are documentation-only but included in release/changelog flow for consistency.

Known follow-ups / intentionally not addressed here:

• SBAT/signing metadata cleanup will be handled separately.
• Gating policy cleanup will be handled separately.
• Inherited helper/tool cleanup (filtermods.py, mod-sign.sh, mod-denylist.sh) is out of scope unless it affects the current Azure Linux package build.

Known CI issue:

• The GitHub “Kernel configs check” workflow already fails and will be addressed in a follow-up pr

Validation

[azureuser@rlmenge-azl4-x64-latest ~]$ uname -a
Linux rlmenge-azl4-x64-latest 6.18.31-1.21.azl4.x86_64 #1 SMP Sat Jul 18 09:38:06 UTC 2026 x86_64 GNU/Linux
[azureuser@rlmenge-azl4-x64-latest ~]$ zcat /proc/config.gz | grep FIP
CONFIG_CRYPTO_FIPS=y
CONFIG_CRYPTO_FIPS_NAME="Linux Kernel Cryptographic API"
# CONFIG_CRYPTO_FIPS_CUSTOM_VERSION is not set
# CONFIG_FIPS_SIGNATURE_SELFTEST is not set

[Copilot]

Pull request overview

Migrates kernel packaging to a maintained local Azure Linux spec and removes unsupported inherited Fedora/RHEL machinery.

Changes:

• Localizes the kernel spec, sources, release metadata, and lock.
• Removes unused architectures, variants, UKI, kABI, and config-generation paths.
• Updates documentation, inspection policy, and module classification.

Reviewed changes

Copilot reviewed 39 out of 100 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
base/comps/kernel/kernel.comp.toml	Switches kernel to a local spec.
base/comps/kernel/kernel.spec	Trims and localizes kernel packaging.
base/comps/kernel/README.rst	Documents Azure Linux maintenance.
base/comps/kernel/rpminspect.yaml	Localizes inspection exceptions.
base/comps/kernel/gating.yaml	Localizes the inherited gating policy.
base/comps/kernel/process_configs.sh	Localizes config validation.
base/comps/kernel/filtermods.py	Localizes module classification logic.
base/comps/kernel/def_variants.yaml.fedora	Updates module package assignments.
base/comps/kernel/x509.genkey.fedora	Updates signing-key generation metadata.
base/comps/kernel/kernel.sbat.template	Localizes the retained SBAT template.
base/comps/kernel/mod-sign.sh	Localizes module-signing support.
base/comps/kernel/mod-denylist.sh	Localizes module denylist generation.
base/comps/kernel/kvm_stat.logrotate	Retains log rotation configuration.
base/comps/kernel/linux-kernel-test.patch	Localizes the retained test patch.
locks/kernel.lock	Updates the local component fingerprint.
specs/k/kernel/kernel.spec	Regenerates the trimmed rendered spec.
specs/k/kernel/sources	Removes obsolete source archives.
specs/k/kernel/README.rst	Renders the Azure Linux README.
specs/k/kernel/rpminspect.yaml	Renders updated inspection policy.
specs/k/kernel/process_configs.sh	Removes unsupported config paths.
specs/k/kernel/x509.genkey.rhel	Removes the RHEL key template.
specs/k/kernel/uki.sbat.template	Removes UKI SBAT data.
specs/k/kernel/uki-addons.sbat.template	Removes UKI addon SBAT data.
specs/k/kernel/uki_create_addons.py	Removes UKI addon generation.
specs/k/kernel/uki_addons.json	Removes UKI addon definitions.
specs/k/kernel/dracut-virt.conf	Removes UKI initramfs configuration.
specs/k/kernel/Patchlist.changelog	Removes inherited patch history.
specs/k/kernel/Makefile.rhelver	Removes RHEL version machinery.
specs/k/kernel/flavors	Removes Fedora/RHEL flavor selection.
specs/k/kernel/generate_all_configs.sh	Removes inherited config generation.
specs/k/kernel/merge.py	Removes config-fragment merging.
specs/k/kernel/kernel-local	Removes local rebuild overrides.
specs/k/kernel/kernel.azl.macros	Inlines Azure Linux macros into the spec.
specs/k/kernel/check-kabi	Removes disabled kABI checking.
specs/k/kernel/partial-kgcov-snip.config	Removes gcov config fragments.
specs/k/kernel/partial-kgcov-debug-snip.config	Removes debug gcov fragments.
specs/k/kernel/partial-clang-snip.config	Removes Clang fragments.
specs/k/kernel/partial-clang-debug-snip.config	Removes debug Clang fragments.
specs/k/kernel/partial-clang_lto-x86_64-snip.config	Removes x86 LTO fragments.
specs/k/kernel/partial-clang_lto-x86_64-debug-snip.config	Removes debug x86 LTO fragments.
specs/k/kernel/partial-clang_lto-aarch64-snip.config	Removes Arm LTO fragments.
specs/k/kernel/partial-clang_lto-aarch64-debug-snip.config	Removes debug Arm LTO fragments.
specs/k/kernel/Module.kabi_x86_64	Removes x86 kABI reference data.
specs/k/kernel/Module.kabi_s390x	Removes s390x kABI reference data.
specs/k/kernel/Module.kabi_riscv64	Removes RISC-V kABI reference data.
specs/k/kernel/Module.kabi_ppc64le	Removes PowerPC kABI reference data.
specs/k/kernel/Module.kabi_dup_x86_64	Removes duplicate x86 kABI data.
specs/k/kernel/Module.kabi_dup_s390x	Removes duplicate s390x kABI data.
specs/k/kernel/Module.kabi_dup_riscv64	Removes duplicate RISC-V kABI data.
specs/k/kernel/Module.kabi_dup_ppc64le	Removes duplicate PowerPC kABI data.
specs/k/kernel/Module.kabi_dup_aarch64	Removes duplicate Arm kABI data.

Comments suppressed due to low confidence (2)

base/comps/kernel/def_variants.yaml.fedora:15

• Removing modules-partner from this package graph is incomplete. Azure Linux sets rhel=10 and not fedora (distro/AGENTS.md:14-16), so kernel.spec still declares kernel-modules-partner, asks filtermods.py for modules-partner.list, and packages that list. This now leaves the expected list/package empty or missing; either retain this package node or remove the non-Fedora partner-package paths from the spec too.
  base/comps/kernel/x509.genkey.fedora:10
• This template is copied to certs/x509.genkey and generates the module-signing key, but the certificate subject now claims to be a Fedora key. That conflicts with the distro vendor (Microsoft Corporation) and the Azure Linux-focused local spec. Replace these fields with the approved Azure Linux module-signing identity.

[Copilot]

Pull request overview

Copilot reviewed 39 out of 100 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (6)

base/comps/kernel/def_variants.yaml.fedora:15

• Removing modules-partner from the filter configuration leaves the spec inconsistent: kernel.spec:1159 still declares the partner subpackage and kernel.spec:1956 unconditionally consumes ../modules-partner.list for Azure Linux (fedora is unset). filtermods.py only writes lists for packages declared here, so a clean build has no modules-partner.list; the build can fail at that call, and the retained subpackage would otherwise be unexpectedly empty. Either retain this package entry or remove all partner-package/list/scriptlet paths from the spec and align rpminspect.
  base/comps/kernel/filtermods.py:25
• Moving this helper under base/ makes it subject to the repository's Python checks, but it already violates them: ruff.toml:1,8,29 scans this path, selects all rules, and requires from __future__ import annotations, while pyrightconfig.json:16-18 rejects the untyped parameters beginning here. This file lacks the required import and has many untyped functions, so the root Ruff/Pyright checks will fail. Bring the file into compliance or add a narrowly justified exclusion for this vendored packaging helper.

def get_td(filename):
    script_dir = os.path.dirname(os.path.realpath(__file__))
    return os.path.join(script_dir, 'filtermods-testdata', filename)


def run_command(cmd, cwddir=None):

base/comps/kernel/kernel.sbat.template:2

• This embeds Red Hat SBAT ownership in Azure Linux kernels. Azure Linux defines rhel=10 (distro/AGENTS.md:16), so kernel.spec:117-125 resolves @SBAT_SUFFIX to rhel; the template is then selected through CONFIG_EFI_SBAT_FILE (kernel.spec:1317,1343). The resulting kernel.rhel/Red Hat record misidentifies this kernel and can couple it to RHEL-targeted SBAT revocations. Use an Azure Linux-specific component suffix, vendor, package identity, and support URL.

kernel.@SBAT_SUFFIX,1,Red Hat,kernel-core,@KVER,mailto:secalert@redhat.com

base/comps/kernel/x509.genkey.fedora:10

• This file is copied to configs/x509.genkey and then to certs/ for module-signing key generation (kernel.spec:1338,1445), so newly built Azure Linux kernels expose a certificate claiming to be the “Fedora kernel signing key.” Replacing the previous CentOS identity with another upstream distro identity contradicts the local Azure Linux packaging; use the approved Microsoft/Azure Linux subject and contact details instead.
  base/comps/kernel/gating.yaml:8
• The retained gating policy still targets rhel-* and requires ppc64le and s390x CKI results, while this PR restricts the kernel to x86_64/aarch64. Because the README now presents this file as active gating support, this policy cannot describe the supported Azure Linux build surface. Replace it with the Azure Linux gating policy and supported architectures, or remove the unused source from the component.

product_versions:
  - rhel-*
decision_context: osci_compose_gate
rules:
  - !PassingTestCaseRule {test_case_name: cki.tier1-aarch64.functional}
  - !PassingTestCaseRule {test_case_name: cki.tier1-ppc64le.functional}
  - !PassingTestCaseRule {test_case_name: cki.tier1-s390x.functional}

base/comps/kernel/process_configs.sh:455

• The first config is processed synchronously here and then immediately processed again in the background with the same count. Besides doubling validation work (the local-spec path copies only one arch config), the second pass rewrites .mismatches0 after the first pass and can erase mismatches once the first pass has normalized the config. Run the first config only synchronously; background only subsequent configs.

		if [ "$count" -eq 0 ]; then
			# do the first one by itself so that tools are built
			process_config "$cfg" "$count"
		fi
		process_config "$cfg" "$count" &

[Copilot]

Pull request overview

Copilot reviewed 39 out of 100 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (7)

base/comps/kernel/def_variants.yaml.fedora:15

• Removing modules-partner here leaves the non-Fedora build path broken. filtermods.py emits one list per package declared in this file, but kernel.spec:1937 still unconditionally consumes ../modules-partner.list on Azure Linux (rhel=10). The file will not be generated, so module-list creation fails. Either retain this package entry or remove the partner package/list path from the spec in the same change.
  base/comps/kernel/filtermods.py:4
• This new Python source is scanned by the root Ruff configuration, which requires from __future__ import annotations in every included Python file (ruff.toml:1,27-29). Without it, the lint workflow fails before this component can merge.

#!/usr/bin/env python3
"""
filter kmods into groups for packaging, see filtermods.adoc
"""

base/comps/kernel/filtermods.py:22

• The newly added module has untyped parameters starting here and throughout its functions. pyrightconfig.json:16-18 makes missing/unknown parameter types and missing type arguments errors for base/, so this file will fail the required Pyright check. Please annotate the module's function parameters and container types before merging.

def get_td(filename):
    script_dir = os.path.dirname(os.path.realpath(__file__))
    return os.path.join(script_dir, 'filtermods-testdata', filename)

base/comps/kernel/kernel.sbat.template:2

• This SBAT record still identifies the binary as Red Hat, and kernel.spec:117-125 resolves @SBAT_SUFFIX to rhel on Azure Linux because the distro defines rhel=10 (distro/AGENTS.md:16). The generated Azure Linux kernel therefore enters the kernel.rhel revocation namespace and advertises Red Hat ownership/contact, so an unrelated RHEL SBAT revocation could reject it. Define an Azure Linux-specific component ID, vendor, and contact and update the spec's suffix selection accordingly.

kernel.@SBAT_SUFFIX,1,Red Hat,kernel-core,@KVER,mailto:secalert@redhat.com

base/comps/kernel/x509.genkey.fedora:10

• This template is copied to certs/x509.genkey, and the shipped configs use CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"; the resulting module-signing certificate therefore claims to be a Fedora key and uses a Fedora contact even though this is an Azure Linux local build. Replace the subject with Azure Linux-controlled organization, common-name, and contact values (and preferably rename the source away from .fedora).
  base/comps/kernel/gating.yaml:8
• This newly retained policy only targets rhel-* in the osci_compose_gate context, while later rules still require ppc64le and s390x tests that this PR explicitly removes from the supported build surface. It cannot gate Azure Linux and contradicts the stated cleanup of inherited variant machinery. Remove this source (and Source4002) or replace it with the actual Azure Linux gating policy.

product_versions:
  - rhel-*
decision_context: osci_compose_gate
rules:
  - !PassingTestCaseRule {test_case_name: cki.tier1-aarch64.functional}
  - !PassingTestCaseRule {test_case_name: cki.tier1-ppc64le.functional}
  - !PassingTestCaseRule {test_case_name: cki.tier1-s390x.functional}

base/comps/kernel/process_configs.sh:455

• The first config is processed synchronously on line 453 and then immediately processed a second time by this unconditional background call using the same counter and temporary filenames. With the new one-config-per-architecture flow, every build runs the expensive Kconfig validation twice. Skip the background call for the first iteration, while preserving counter/job bookkeeping for subsequent configs.

		if [ "$count" -eq 0 ]; then
			# do the first one by itself so that tools are built
			process_config "$cfg" "$count"
		fi
		process_config "$cfg" "$count" &

[Copilot]

Pull request overview

Copilot reviewed 39 out of 100 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (4)

base/comps/kernel/filtermods.py:4

• This authored Python source is now under the repository's Ruff and Pyright scan scope, but it is not compliant: ruff.toml:29 requires from __future__ import annotations, and pyrightconfig.json:16-18 rejects the many untyped parameters in this file (for example get_td, run_command, and safe_run_command). The rendered copy under specs/ is excluded, but this source copy is not, so Python CI will fail until the file is typed/linted or an explicit project-approved exclusion is added.

#!/usr/bin/env python3
"""
filter kmods into groups for packaging, see filtermods.adoc
"""

base/comps/kernel/filtermods.py:751

• This appends kmod_parent while iterating conflicting children. It reports the wrong module and can raise UnboundLocalError when the current kmod has no parents, causing filtermods.py sort to fail during the build's report phase. Append the current child instead.

        for kmod_child in kmod.depends_on:
            if not is_pkg_parent_to_any(kmod.preferred_pkg, kmod_child.allowed_list):
                bad_child_list.append(kmod_parent)

base/comps/kernel/def_variants.yaml.fedora:15

• Removing modules-partner here is incomplete: kernel.spec:1158-1160 still creates the package, kernel.spec:1936-1938 still consumes ../modules-partner.list, and kernel.spec:3206-3208 still uses that list in %files. filtermods.py emits lists only for packages declared in this YAML, so the list is no longer generated while the stale package path remains. Remove the partner package/install/files branches from the spec as part of this cleanup, or retain this package definition until that machinery is removed.
  base/comps/kernel/mod-denylist.sh:29
• This condition tests whether the nonempty string in mod is logically false, so it never skips a missing module. A stale module-list entry is consequently passed to modinfo instead of being ignored. Test filesystem existence explicitly.

	mod="$rpm_buildroot/$1"
	[ ! "$mod" ] && return 0
	if modinfo "$mod" | grep -q '^alias:\s\+net-'; then

[Copilot]

Pull request overview

Copilot reviewed 39 out of 100 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

base/comps/kernel/def_variants.yaml.fedora:15

• Removing modules-partner from the classifier does not remove that RPM. The local spec still expands kernel_modules_partner_package, creates a partner file list/directory, and declares its %files section when %fedora is undefined (kernel.spec:1158-1160, 1936-1937, 3206-3208). This therefore continues emitting the stale kernel-modules-partner package even though the classifier can no longer assign modules to it, contradicting this PR's package-path cleanup. Remove the corresponding package/list/scriptlet/files paths from the local spec, or retain a real classifier mapping if the package is still intended.

[Copilot]

Pull request overview

Copilot reviewed 39 out of 100 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

base/comps/kernel/filtermods.py:1

• Moving this inherited helper under base/ makes it subject to the repository’s Python checks, but it lacks the required future import and has many untyped parameters. ruff.toml:1,8,29 scans this path with all rules and requires from __future__ import annotations; pyrightconfig.json:2-18 also scans it and treats missing/unknown parameter types as errors. Please either make the helper compliant or add narrowly documented exclusions for this vendored source to both tools.

#!/usr/bin/env python3