What was the reason for this change? Our eclass in question can be seen here: https://github.com/GenPi64/genpi64-overlay/blob/133f973d44f080f94ddefa43761ecef1399d643a/eclass/pikernel-build.eclass Our ebuild in question is here: https://github.com/GenPi64/genpi64-overlay/blob/133f973d44f080f94ddefa43761ecef1399d643a/sys-kernel/raspberrypi-kernel/raspberrypi-kernel-5.10.11.ebuild Build log is attached.
Created attachment 757190 [details] Build logs, too big without compression
The reason is that I've failed to bump genpatches version in the past and it resulted in building the wrong kernel version.
So is the best option to basically create our own kernel-install_pkg_preinst() function in the eclass that overwrites your change, or what's the better thing to do about this?
Is there a specific reason you're not installing the release file? Or does the eclass get the path wrong?
(In reply to Skyler Mäntysaari from comment #3) > So is the best option to basically create our own > kernel-install_pkg_preinst() function in the eclass that overwrites your > change, or what's the better thing to do about this? I feel like you've come at this from the wrong angle here. mgorny's question is the same as mine. Could you explain why this logic isn't working for you? We're not being adverserial here, we want it to work for you too, so let's talk about what you need. You don't need to jump to overriding functions forever. I'd assumed this was possibly b/c not using genpatches but you are. (FWIW, I think I'd be open to having something like this / importing these in ::gentoo. I really would like it if we could talk more and we could import more stuff (with you maintaining it if you wish!) rather than just keeping it in an overla yforever.)
Ultimately I think the reason its not working for us is simply that our kernel ebuild didn't have a reason to deploy the kernel.release file until the commit that added the check for it. Our ebuild produces multiple kernels from the same source code, since we're targeting the raspberry pi platform, we build a distinct kernel for each board that we support. So it's hard to know which of those kernel.release files should be the one that gets installed to the location marked by "relfile". /// Copied from https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e893119949ec1f94b83dc467514dc9ad4495a596 local ver="${PV}${KV_LOCALVERSION}" local kdir="${ED}/usr/src/linux-${ver}" local relfile="${kdir}/include/config/kernel.release" You'll see in this code block here: /// copied from https://github.com/GenPi64/genpi64-overlay/blob/72aa8f467995b86d1378b21e8e230b4414df0f72/eclass/pikernel-build.eclass#L158 # note: we're using mv rather than doins to save space and time # install main and arch-specific headers first, and scripts local kern_arch=$(tc-arch-kernel) local ver="${PV}" dodir "/usr/src/linux-${ver}/arch/${kern_arch}" mv include scripts "${ED}/usr/src/linux-${ver}/" || die mv "arch/${kern_arch}/include" \ "${ED}/usr/src/linux-${ver}/arch/${kern_arch}/" || die That we're coping the "include" dir to "${ED}/usr/src/linux-${ver}/", but that apparently doesn't have the kernel.release file either. In our builds, the kernel.release file is not the same for each board we're building a kernel for. E.g ymir ~/genpi64/openrc/chroot/var/tmp/portage/sys-kernel/raspberrypi-kernel-5.10.11/work # find . -name "*kernel.release*" ./bcmrpi3/include/config/kernel.release ./bcm2711/include/config/kernel.release ymir ~/genpi64/openrc/chroot/var/tmp/portage/sys-kernel/raspberrypi-kernel-5.10.11/work # cat ./bcm2711/include/config/kernel.release ./bcmrpi3/include/config/kernel.release 5.10.11-v8-p4 5.10.11-v8 Which of these two files should be installed? If we just wanted to hack it together, picking one and being consistent would be sufficient, i suppose, but obviously that defeats the point. As for whether or not to have closer integration with the ::gentoo repository, I'm all for that. We don't have any particular need to control the ebuild for our kernel, its just what we got working. If you have a suggestion for a different way to approach the raspberry pi board kernel, happy to listen.
Right, after discussing on IRC, I get it now. The issue more broadly is, how do we properly support multiple different targets in kernel-{build,install}.eclass? For your case, it makes sense to use a single ebuild for it and have a single binpkg at the end (because you need a bunch of different .imgs on RPi). We didn't consider that case until now.
