sys-kernel/raspberrypi-{image, sources}: add 6.1

[vimproved]

No description provided.

[gentoo-bot]

Pull Request assignment

Submitter: @vi-improved
Areas affected: ebuilds
Packages affected: sys-kernel/raspberrypi-image, sys-kernel/raspberrypi-sources

sys-kernel/raspberrypi-image: @thesamesam
sys-kernel/raspberrypi-sources: @thesamesam, @expeditioneer

Linked bugs

No bugs to link found. If your pull request references any of the Gentoo bug reports, please add appropriate GLEP 66 tags to the commit message and request reassignment.

If you do not receive any reply to this pull request, please open or link a bug to attract the attention of maintainers.

---

In order to force reassignment and/or bug reference scan, please append [please reassign] to the pull request title.

Docs: Code of Conduct ● Copyright policy (expl.) ● Devmanual ● GitHub PRs ● Proxy-maint guide

[vimproved]

Literally no idea what the CI is on about, I don't see any issues introduced by this PR and neither did pkgcheck.

[thesamesam]

Please rebase on master (809d708 fixes CI). The issue is hidden in the global section (got to scroll) but was not your fault or related to this PR.

[vimproved]

Shoot, my bad. Apparently I forgot how to use git.

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2023-05-16 14:23 UTC
Newest commit scanned: 95ad436
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/6b074bdd4b/output.html

[vimproved]

Could this possibly be looked at again?

[xandris]

Getting this during prepare:

* Failed to dry-run patch 1700_sparc-address-warray-bound-warnings.patch

It's trying to patch arch/sparc/mm/init_64.c but patch can't find it. $PWD ends up being $WORKDIR instead of $S during patching, probably because the universal_unpack override in the ebuild doesn't cd "${S}" like in the eclass. The GENPATCHES upgrade from 22 to 25 exposed this problem I think because it added patch 1700 whereas before all patches were excluded and this was never exercised.

Also, files/*.patch didn't apply either. I had to tweak it a bit as some of the kconfig sections were missing.

--- /var/db/repos/gentoo/sys-kernel/raspberrypi-sources/files/raspberrypi-sources-5.15.32-gentoo-kconfig.patch  2023-03-22 18:53:07.010408322 +0000
+++ files/raspberrypi-sources-6.1.21-gentoo-kconfig.patch       2023-06-08 16:45:05.788187166 +0000
@@ -404,6 +404,7 @@
  config FW_LOADER_USER_HELPER
        bool "Enable the firmware sysfs fallback mechanism"
 +      depends on !GENTOO_LINUX_INIT_SYSTEMD
+       select FW_LOADER_SYSFS
        select FW_LOADER_PAGED_BUF
        help
          This option enables a sysfs loading facility to enable firmware
@@ -440,26 +441,6 @@
        default 4096
        help
          This is the portion of low virtual memory which should be protected
-diff --git a/security/Kconfig b/security/Kconfig
-index fe6c0395fa02..6b1b81cd120e 100644
---- a/security/Kconfig
-+++ b/security/Kconfig
-@@ -166,6 +166,7 @@ config HARDENED_USERCOPY
- config HARDENED_USERCOPY_FALLBACK
-       bool "Allow usercopy whitelist violations to fallback to object size"
-       depends on HARDENED_USERCOPY
-+      depends on !GENTOO_KERNEL_SELF_PROTECTION
-       default y
-       help
-         This is a temporary option that allows missing usercopy whitelists
-@@ -181,6 +182,7 @@ config HARDENED_USERCOPY_PAGESPAN
-       bool "Refuse to copy allocations that span multiple pages"
-       depends on HARDENED_USERCOPY
-       depends on EXPERT
-+      depends on !GENTOO_KERNEL_SELF_PROTECTION
-       help
-         When a multi-page allocation is done without __GFP_COMP,
-         hardened usercopy will reject attempts to copy it. There are,
 diff --git a/security/selinux/Kconfig b/security/selinux/Kconfig
 index 9e921fc72538..9e1f7ce887b6 100644
 --- a/security/selinux/Kconfig

I can open a PR when I get home tonight if these findings are valid.

[vimproved]

Shoot. No idea how I didn't catch that, sorry.

[xandris]

No worries it wasn't hard to work around. Thank you for the version bump