On Fri, Nov 3, 2023 at 8:52 AM Bruce Ashfield via lists.yoctoproject.org <[email protected]> wrote: > > On Fri, Nov 3, 2023 at 5:15 AM Sverdlin, Alexander > <[email protected]> wrote: > > > > Hello Bruce, > > > > thanks for the quick reply! > > > > On Thu, 2023-11-02 at 15:13 -0400, Bruce Ashfield wrote: > > > > My current understanding is that > > > > meta-virtualization/recipes-kernel/linux/linux-yocto_virtualization.inc > > > > makes an assumption that any type=kmeta will point to upstream > > > > git://git.yoctoproject.org/yocto-kernel-cache but this doesn't hold > > > > for my use case. > > > > > > close. > > > > > > The support assumes that if something is on the src_uri named > > > "kernel-cache" that it is a complete, similarly formatted repository > > > to the upstream / centralized one that I maintain > > > > > > If that is found, it is preferred over the yocto-kernel-cache provided > > > by the yocto-cfg-fragments recipe. > > > > [...] > > > > > > The only type=kmeta is my local file:// storage and the following > > > > linux-yocto_virtualization.inc part leads to fetch failure (fetch > > > > from Internet not expected/forbidden): > > > > > > > > # if kernel-yocto has been inherited (how we can check for configuration > > > > # fragment merging suport at the moment, then add a dependency on the > > > > # configuration fragment repository. This allows us to be sure that our > > > > # features can be enabled via the fragments > > > > do_kernel_metadata[depends] += "${@['', > > > > 'yocto-cfg-fragments-native:do_populate_sysroot'][(bb.data.inherits_class('kernel-yocto', > > > > d))]}" > > > > > > > > Summary: 1 task failed: > > > > virtual:native:.../projects/ccp-sd-virt/../../meta-virtualization/recipes-kernel/linux/yocto-cfg-fragments.bb:do_fetch > > > > > > At a glance, I'm not seeing how your local kmeta is causing > > > the full fragments recipe to fail to fetch. > > > > > > > Fetch failure is expected, as there is simply no access to outside world and > > all expected packages are mirrored. > > Now the real issue is that providing local type=kmeta pulls > > git://git.yoctoproject.org/yocto-kernel-cache and currently we require no > > of the upstream fragments, so there is no point in mirroring the > > yocto-kernel-cache > > repo just to satisfy fetch as we don't require these features. > > if you are enabling the virtualization distro feature, and are including > meta-virtualization, that repository is a requirement. That's how it > ensures that subtle runtime errors don't creep in with incorrect kernel > configurations. > > So why not just mirror it ? > > > > > Currently I see no way to control this behaviour... > > > > > > When I read the comment "if the kernel-yocto meta-data routine > > > > automatically > > > > starts to add the recipe-sysroot-native..." I get a feeling that > > > > this feature is still "work in progress". Are there any further > > > > developments > > > > I could test in this direction? > > > > > > There's nothing that would fix that issue. The in-progress part of that > > > is that I plan to remove all of the local fragments in the virtualization > > > layer and rely on the cloned kernel-cache from that recipe. > > > > > > I don't suppose there's a layer I can look at which has your fragments > > > and the related kernel bbappend ? I'd like to reproduce the issue > > > locally so I can debug it in more detail. > > > > I cannot easily point you to something publicly available... But roughly > > it's a > > combination of meta-virtualization and a kernel recipe derived from > > kernel-yocto.bbclass. > > > > Now I long as one doesn't have any type=kmeta, meta-virtualization doesn't > > pull > > git://git.yoctoproject.org/yocto-kernel-cache and adding > > "file://features/debug;type=kmeta;destsuffix=features/debug" to SRC_URI > > causes > > yocto-kernel-cache to be pulled even though there is no logical reason for > > this. > > That's not what my local tests show. It is keying off an inherit of > kernel-yocto, > not kmeta, but even by extension, seeing that fragment merging is available > (whether keyed of kmeta or the inherit of kernel-yocto), that is the logic as > to > why it pulls it in (and the use of it is what I explained above).
Cancel that comment, I do see it now. And yes, if there's any kmeta fragments in the SRC_URI that is used to construct the kernel include file name, which then double checks if kernel-yocto is inherited, and the combination of the two indicates that the fragments should be made available for the packages in the layer to be properly supported at runtime. There should be a way for you to manipulate the do_kernel_metadata[depends] value in your own bbappend to remove the dependency on the repo. I can also try and think up another variable or a way to exclude that dependency .. but again, it is an intended dependency, and I was trying for a lighter touch with the existing checks, and I don't want to make them too complex or introduce a bug where the fragments stop being pulled in where they have currently been pulled as a dependency. Bruce > > Unless I have a way to see the issue locally, I can't easily address it (if > required). > > Bruce > > > > > -- > > Alexander Sverdlin > > Siemens AG > > www.siemens.com > > > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > - "Use the force Harry" - Gandalf, Star Trek II > > > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#8417): https://lists.yoctoproject.org/g/meta-virtualization/message/8417 Mute This Topic: https://lists.yoctoproject.org/mt/102338788/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/leave/6693005/21656/1014668956/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
