linux3.4-ARM-8933-1-replace-Sun-Solaris-style-flag-on-section-xz-supplementation.patch
contains an addition that was not part of
linux3.4-ARM-8933-1-replace-Sun-Solaris-style-flag-on-section.patch
simply because error did not occur with the config I tested with.
[ci:skip-build]: already built successfully in CI
With recent gcc versions we get errors like:
/linux/arch/arm/mm/proc-v7.S: Assembler messages:
/linux/arch/arm/mm/proc-v7.S:425: Error: junk at end of line, first unrecognized character is `#'
Seen on at least two samsung kernels based on 3.4 and 3.10. Fix issue
by backporting (part of) commit found in mainline.
Merge and move Spreadtrum patches from these kernels to shared-patches:
* linux-finepower-f1
* linux-samsung-{gtel3g,gtelwifi,j1mini3g,j3xnlte}
* linux-zte-p731a20
[ci:skip-build]: already built successfully in CI
These are various debugging related patches that I have used over the time
when attempting to get new features working for the mainline kernel.
Given that the downstream kernel is just intended for debugging in this case,
it seems convenient to add them to pmaports so I don't need to go search for
them in case I need them again in the future.
[ci:skip-build] Already built on CI
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]
All the downstream kernels reference ../../.shared-patches in their
symlinks. Now that we have moved device ports to device/testing/*,
those symlinks are no longer working.
Changing the path would require fixing all downstream packages *and*
a new pmbootstrap release. Overall it seems easier to move the
.shared-patches folder to device/.shared-patches.
Since it is only relevant for downstream kernel packages in device/
that might be a better place in general.
