This was done in 7 steps:
* prepare by running pmbootstrap kconfig migrate
* fix up kconfig category:uefi
* fix up kconfig category:zram
* fix up kconfig category:default
* fix up kconfig category:default (NULL_TTY)
* fix up kconfig category:input
* bump pkgrels
[ci:skip-build]
[ci:ignore-count]
Too many kconfig checks fail for these. The kconfig check is more strict
now, it will not pass anymore if a kernel claims to support everything
for the "community" category but doesn't actually satisfy the
requirements. Previously it did pass and only printed warnings.
The "pmb:kconfigcheck-community" option may be added back to these
kernels after the configs are adjusted.
This is required by some software, e.g. bluez/gnome to set some ACLs on
/dev/rfkill (see #904). While probably nobody will notice on the
downstream kernels (as we don't have any proper software there anyways)
it's definitely needed on mainline-ish kernels. Surprisingly only one
kernel has broken by enabling this option (linux-sony-tulip) which I've
patched up.
linux-postmarketos-qcom-sdm660 did not break by enabling this option,
but required linux4.17-gcc10-extern_YYLOC_global_declaration.patch to
build again, so this was fixed too.
[ci:skip-build] [ci:ignore-count]
Mostly the GCC10 yylloc failure was seen but several others have been
observed:
* wireguard script was silently failing
* several gcc10 x86 errors
* a checksum from kernel.org has changed
Now we have 3 different gcc10 yylloc patches:
gcc10-extern_YYLOC_global_declaration.patch:
Linux < 4.2
linux4.2-gcc10-extern_YYLOC_global_declaration.patch:
Linux 4.2+
linux4.17-gcc10-extern_YYLOC_global_declaration.patch:
Linux 4.17+
[ci:skip-build]
[ci:ignore-count]
[ci:skip-vercheck]
Enable CONFIG_CRYPTO_XTS for each kernel, so we can switch to using
aes-xts-plain64 as default cipher for cryptsetup (override with
"pmbootstrap --cipher"), instead of aes-cbc-plain64 (pmbootstrap#1940).
I have executed "pmbootstrap kconfig edit" on each kernel, and manually
toggled the option. The diff is not always clean, because for some
kernels it is apparently the first time, that menuconfig was executed on
the configs like that. In a few instances, it turned out that
CONFIG_ANDROID_PARANOID_NETWORK needed to be disabled too (this is
already a requirement, but as the config was incomplete, it was not
visible that this option was enabled). Very few times, I had to enable
CONFIG_EXPERIMENTAL in order to see and enable CONFIG_CRYPTO_XTS.
It would be great if we could automate such mass kconfig edits in the
future, see pmbootstrap#1942.
[skip ci]: I have verified, that every single one of these kernels builds.
CI will likely run out of time while downloading source tarballs.
Prepare for better device categorization by moving everything to testing
subdir first.
[skip-ci]: chicken-egg problem: passing pmaports CI depends on pmbootstrap MR
depends on this MR
Related: postmarketos#16
Achill Gilgenast