kernel-build.class: Allow usage with module-less kernel configs #32358
Conversation
Pull Request assignmentSubmitter: @bstaletic @gentoo/github Linked bugsBugs linked: 904694 New packagesThis Pull Request appears to be introducing new packages only. Due to limited manpower, adding new packages is considered low priority. This does not mean that your Pull Request will not receive any attention, however, it might take quite some time for it to be reviewed. In the meantime, your new ebuild might find a home in the GURU project repository: the ebuild repository maintained collaboratively by Gentoo users. GURU offers your ebuild a place to be reviewed and improved by other Gentoo users, while making it easy for Gentoo users to install it and enjoy the software it adds. Missing GCO sign-offPlease read the terms of Gentoo Certificate of Origin and acknowledge them by adding a sign-off to all your commits. In order to force reassignment and/or bug reference scan, please append Docs: Code of Conduct ● Copyright policy (expl.) ● Devmanual ● GitHub PRs ● Proxy-maint guide |
gentoo-bot
added
need assignment
Pull request CI reportReport generated at: 2023-08-17 17:30 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
eclass/kernel-build.eclass
Outdated
| [[ ! -f "${ED}${kernel_dir}/include/config/kernel.release" ]] && cp "${WORKDIR}/build/include/config/kernel.release" "${ED}${kernel_dir}/include/config/" | ||
| local relfile=${ED}${kernel_dir}/include/config/kernel.release |
There was a problem hiding this comment.
I think it's fine to just change relfile if the other path is fine for both scenarios.
There was a problem hiding this comment.
We could for this specific case, but if kernel.release is not installed it will cause problems in other places.
I have finally figured out what is going on with kernel.release and was able to avoid this ugly check-and-copy. In short, with modules, kernel.release ends up in modprep directory and is then installed from there. That does not happen without modules.
bstaletic
force-pushed
the
kernel-build-fix
branch
2 times, most recently
from
ab343d6
to
919a738
Compare
Pull request CI reportReport generated at: 2023-08-19 09:36 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
I did add a sign-off to the commit. Is anything else missing? |
We need to remove that manually, sorry. |
Pull request CI reportReport generated at: 2023-08-19 09:51 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
bstaletic
force-pushed
the
kernel-build-fix
branch
from
919a738
to
ad14deb
Compare
With CONFIG_MODULES not set to either y or m, kernel-build.eclass runs
into two issues:
1. Modules.symvers does not get generated. doins build/Module.symvers
thus fails.
2. kernel.release exists, but in ${WORKDIR}/build/include/config/kernel.release
while kernel-build_src_install() seems to expect to to find it in ${PWD}/include/config
Closes: https://bugs.gentoo.org/904694
Signed-off-by: Boris Staletic <boris.staletic@protonmail.com>
Pull request CI reportReport generated at: 2023-08-20 15:26 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
|
Thanks! |
With CONFIG_MODULES not set to either y or m, kernel-build.eclass runs
into two issues:
1. Modules.symvers does not get generated. doins build/Module.symvers
thus fails.
2. kernel.release exists,
but in ${WORKDIR}/build/include/config/kernel.release
while kernel-build_src_install() seems to expect to to find it
in ${PWD}/include/config.
Closes: https://bugs.gentoo.org/904694
Signed-off-by: Boris Staletic <boris.staletic@protonmail.com>
Closes: gentoo#32358
Signed-off-by: Michał Górny <mgorny@gentoo.org>
With CONFIG_MODULES not set to either y or m, kernel-build.eclass runs into two issues:
Closes: https://bugs.gentoo.org/904694