Hi Alexander!
On Thu, Nov 2, 2023 at 6:24 AM Sverdlin, Alexander
<alexander.sverd...@siemens.com> wrote:
>
> Hello Bruce!
>
> Trying to understand the usage of SRC_URI type=kmeta/kernel-cache in
> commits
> 5c2129118797 ("virtualization/config: allow conditional use of
> yocto-cfg-fragments")
> and 5be8686e659c ("kernel: fix conditional application of fragments").
>
> I have an issue implementing some locally-maintained fragments, I'm adding
> "file://features/debug;type=kmeta;destsuffix=features/debug" to SRC_URI in my
> kernel recipe derived from kernel-yocto class and this actually works
> fine for me until I try to combine this with meta-virtualization.
>
> 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.
That's why I have the similarly formatted stipulation above, since
it is locating a fragment based on a name and relative path. I could
easily drop that stipulation by doing more advanced searching,
but that hasn't been required so far.
All the above assumes that I don't have bugs in the implementation :)
side note: I just updated the yocto-cfg-fragments recipe to the latest
6.5 SRCREVs.
>
> 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.
>
> 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.
Bruce
>
> What would be a proper resolution of the above type=kmeta usage conflict from
> your PoV?
>
> --
> 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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8413):
https://lists.yoctoproject.org/g/meta-virtualization/message/8413
Mute This Topic: https://lists.yoctoproject.org/mt/102338788/21656
Group Owner: meta-virtualization+ow...@lists.yoctoproject.org
Unsubscribe:
https://lists.yoctoproject.org/g/meta-virtualization/leave/6693005/21656/1014668956/xyzzy
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
