Draft: parse.kconfig: support checking generated kconfig from fragments

This teaches kconfig check to generate and validate kconfig that was generated by abuild prepare, e.g. when using config fragments.

If the standard *.config files are not found in pmaports for a kernel package, then it runs abuild unpack && abuild prepare to unpack the kernel source, apply patches, and (for pkgs that use fragments) generate a config based on those fragments. After this, it runs the check on that generated config.

It seems kinda wasteful to be downloading/extracting the kernel source just to validate the kconfig, but I think that in most situations where the kconfig is being checked, the kernel source is already being downloaded for other reasons (build testing / checksumming in CI or locally). Obviously there are exceptions and this way of doing kconfig check could be annoying (making broad kernel changes in CI), but I still think it's not that bad since 1) very few kernels in pmaports use fragments, and 2) we can improve this later if the first point changes significantly

I used this on a kernel pkg being developed in pmaports!5837 (merged) and it found real kconfig check failures with some earlier version of the kconfig fragments in that patch:

[11:46:14] WARNING: .config: CONFIG_LEDS_TRIGGER_PATTERN should be set (category:community_various)
[11:46:14] WARNING: .config: CONFIG_NETFILTER_XT_MATCH_MARK should be set (category:community_various)
[11:46:14] WARNING: .config: CONFIG_NETFILTER_XT_MATCH_MULTIPORT should be set (category:community_various)
[11:46:14] WARNING: .config: CONFIG_NETFILTER_XT_MATCH_STATISTIC should be set (category:community_various)
[11:46:14] WARNING: .config: CONFIG_UCLAMP_TASK should be set (category:community_various)
[11:46:14] WARNING: .config: CONFIG_UCLAMP_TASK_GROUP should be set (category:community_various)
[11:46:14] WARNING: .config: CONFIG_RT_GROUP_SCHED should *not* be set (category:community_various)
[11:46:14] WARNING: .config: CONFIG_DM_INTEGRITY should be set (category:community_various)
[11:46:14] WARNING: .config: CONFIG_NFT_COMPAT should be set (category:containers)
[11:46:14] WARNING: .config: CONFIG_DYNAMIC_FTRACE should be set (category:debug)
[11:46:14] WARNING: .config: CONFIG_UDF_FS should be set (category:filesystems)
[11:46:14] WARNING: .config: CONFIG_XFS_FS should be set (category:filesystems)
[11:46:14] WARNING: .config: CONFIG_HIDRAW should be set (category:input)
[11:46:14] WARNING: .config: CONFIG_JOYSTICK_XPAD should be set (category:input)
[11:46:14] WARNING: .config: CONFIG_JOYSTICK_XPAD_FF should be set (category:input)
[11:46:14] WARNING: .config: CONFIG_JOYSTICK_XPAD_LEDS should be set (category:input)
[11:46:14] WARNING: .config: CONFIG_USB_ANNOUNCE_NEW_DEVICES should be set (category:input)
[11:46:14] WARNING: .config: CONFIG_USB_HIDDEV should be set (category:input)
[11:46:14] WARNING: .config: CONFIG_USB_PRINTER should be set (category:input)

changed the description

The output from abuild prepare is kinda annoying, it prints a lot of messages like this while it runs/merges fragments:

Value of CONFIG_CONNECTOR is redefined by fragment ./arch/arm64/configs/misc.config:
Previous value: # CONFIG_CONNECTOR is not set
New value: CONFIG_CONNECTOR=y

Value of CONFIG_CIFS is redefined by fragment ./arch/arm64/configs/misc.config:
Previous value: # CONFIG_CIFS is not set
New value: CONFIG_CIFS=y

#
# merged configuration written to .config (needs make)
#
#
# configuration written to .config
#

This makes it hard to spot kconfig check failures when testing multiple kernels.

kconfig line failures no longer reference the specific kernel that failed, e.g.:

[11:46:14] WARNING: .config: CONFIG_DM_INTEGRITY should be set (category:community_various)

Normally it should say something like:

[11:59:51] WARNING: config-lenovo-21bx.aarch64: CONFIG_...

Printing info about the kernel pkg (name, arch) makes it easier for users to identify where changes need to be made.

added 1 commit

• 58233c18 - parse.kconfig: support checking generated kconfig from fragments

Compare with previous version

added 1 commit

• 590e6663 - parse.kconfig: support checking generated kconfig from fragments

Compare with previous version

added 1 commit

• 9faf547b - parse.kconfig: support checking generated kconfig from fragments

Compare with previous version

added 1 commit

• b9f172c1 - parse.kconfig: support checking generated kconfig from fragments

Compare with previous version

mentioned in commit pmaports@8fae6abd

this is awesome! thanks for implementing it

added 1 commit

• 74c27944 - parse.kconfig: support checking generated kconfig from fragments

Compare with previous version

mentioned in commit pmaports@ce79aa47

mentioned in commit pmaports@086c54c8

mentioned in commit pmaports@fefe267a

mentioned in commit pmaports@a4289529

Hm, I think some of our kernel APKBUILDs build "out of tree" (i.e. in a separate output directory), e.g. like in pmaports!5814 (22302be2). Do we need to handle _outdir here?

Not sure, @caleb ? That patch isn't even merged yet, so if linux-next is the only example of this then maybe we improve this later when that is merged?

changed this line in version 12 of the diff

added 2 commits

• 91f0a4fe - 1 commit from branch master
• 1a83ce87 - parse.kconfig: support checking generated kconfig from fragments

Compare with previous version

This is amazing!

It seems kinda wasteful to be downloading/extracting the kernel source just to validate the kconfig, but I think that in most situations where the kconfig is being checked, the kernel source is already being downloaded for other reasons (build testing / checksumming in CI or locally). Obviously there are exceptions and this way of doing kconfig check could be annoying (making broad kernel changes in CI), but I still think it's not that bad since 1) very few kernels in pmaports use fragments, and 2) we can improve this later if the first point changes significantly

Idea to fix this: add a custom variable to the APKBUILD that points directly to the kernel config URL. Then we would only need to download and that and could avoid the extraction step (?)

If you think this is out-of-scope for this MR, feel free to resolve this here.

There is no kernel config URL because the kernel config for these kernels is generated at abuild time in the prepare() function. The current implementation for that (using linux-next as an example) requires running stuff like make on the kernel tree to merge fragments and generate a .config, so I don't think we can link to anything useful that doesn't require extracting the kernel source

added 34 commits

• 1a83ce87...47984a87 - 33 commits from branch master
• a77c39a1 - parse.kconfig: support checking generated kconfig from fragments

Compare with previous version