<div dir="ltr">Hi Mikko, thanks for pointing out the buildhistory.<div>I need to have a look at it also as I haven't used it yet.</div><div>Also, it's very nice to see it documented so well.</div><div><br></div><div>Thanks!</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 29, 2019 at 9:59 AM <<a href="mailto:Mikko.Rapeli@bmw.de">Mikko.Rapeli@bmw.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Mar 29, 2019 at 09:50:20AM +0100, Dimitris Tassopoulos wrote:<br>
> Hi all,<br>
> <br>
> I was thinking that the mail list shouldn't be only for problems and<br>
> questions and that from time to time, it would be nice to see some guides,<br>
> tutorials or success stories from people that follow the list.<br>
> <br>
> Anyway, a few days ago someone had an issue with one of the BSPs I'm<br>
> maintaining and I wrote him a small guide on how to -try- to resolve future<br>
> issues like that. Then I thought that I haven't found a small tutorial<br>
> like this. Maybe it already exists, but nevertheless I haven't seen it.<br>
> Of course, those things are in the documentation, but they are documented<br>
> as individual tools (which is the correct thing to do), but it's not very<br>
> clear how to use all those things together to perform more complex tasks.<br>
> <br>
> So, in my case the issue was that ofono was installed in the image and that<br>
> needed to be removed. Probably a lot of you already know the answer but for<br>
> me that I've never bothered with that I had to track it down how it got in<br>
> there.<br>
> <br>
> Everything from now on assumes that you've setup up your bitbake environment<br>
> of your build with whatever setup scripts you're using (e.g.<br>
> *oe-init-build-env*)<br>
> <br>
> There are several ways to do introspection on an image. For example,<br>
> let's say that you found a file in the in rootfs and you want to know which<br>
> recipe added that file. Then you can use this command:<br>
> <br>
> oe-pkgdata-util find-path /usr/sbin/ofonod<br>
> <br>
> <br>
> *oe-pkgdata-util* is a utility in *poky/scripts/oe-pkgdata-util* and<br>
> `find-path` is pretty obvious what it does. This will return:<br>
> <br>
> ofono: /usr/sbin/ofonod<br>
> <br>
> <br>
> So now you know that it's indeed the *ofono* recipe that adds this file.<br>
> Next,<br>
> you need how this did get in the image (probably some other dependency<br>
> because you didn't). Then you can use the `-g` parameter with bitbake like<br>
> this:<br>
> <br>
> bitbake -g allwinner-image<br>
> <br>
> <br>
> This will create a file called `recipe-depends.dot`. This is a dot file that<br>
> has all the dependencies in the image. You can use the same command to get<br>
> the dependencies for a recipe, but now we care about the image.<br>
> <br>
> Next step is to search in that file, why that key is there. Why is `-w` and<br>
> key is `-k`. You can always remember this as "-w-hy that -k-ey is there?"<br>
> and you<br>
> run this command:<br>
> <br>
> oe-depends-dot -k ofono -w recipe-depends.dot<br>
> <br>
> <br>
> This will return the recipe that has this as dependency.<br>
> <br>
> <br>
> > Because: allwinner-image packagegroup-base<br>
> <br>
> <br>
> That means that the key is there because of allwinner-image (this is the<br>
> image<br>
> recipe, but it can be any other image) and because the *allwinner-image*<br>
> inherits the<br>
> *packagegroup-base*. So this packagegroup is the guilty.<br>
> <br>
> Let's find this thing now. Get in the meta layer sources folder and run this<br>
> <br>
> find . | grep packagegroup-base<br>
> <br>
> <br>
> This will return<br>
> <br>
> > ./poky/meta/recipes-core/packagegroups/<a href="http://packagegroup-base.bb" rel="noreferrer" target="_blank">packagegroup-base.bb</a><br>
> <br>
> <br>
> Great. Open this file to an editor and find where is *ofono*. Gotcha, is in:<br>
> <br>
> RDEPENDS_packagegroup-base-3g<br>
> <br>
> <br>
> Then it's the *packagegroup-base-3g* that does that. Probably that's a<br>
> recipe<br>
> or package group file, so you can run:<br>
> <br>
> find . | grep packagegroup-base-3g<br>
> <br>
> <br>
> But you get nothing... Then probably this is declared somewhere a file with<br>
> another name, so let's search inside the files in the poky layer:<br>
> <br>
> grep -nriI ackagegroup-base-3g<br>
> <br>
> <br>
> And we get:<br>
> <br>
> poky/meta/recipes-core/packagegroups/<a href="http://packagegroup-base.bb:35" rel="noreferrer" target="_blank">packagegroup-base.bb:35</a>:<br>
> > ${@bb.utils.contains("DISTRO_FEATURES", "3g", "packagegroup-base-3g", "",<br>
> > d)} \<br>
> > poky/meta/recipes-core/packagegroups/<a href="http://packagegroup-base.bb:73" rel="noreferrer" target="_blank">packagegroup-base.bb:73</a>:<br>
> > ${@bb.utils.contains('COMBINED_FEATURES', '3g', 'packagegroup-base-3g',<br>
> > '',d)} \<br>
> > poky/meta/recipes-core/packagegroups/<a href="http://packagegroup-base.bb:122" rel="noreferrer" target="_blank">packagegroup-base.bb:122</a>:<br>
> > d.setVar("ADD_3G", "packagegroup-base-3g")<br>
> > poky/meta/recipes-core/packagegroups/packagegroup-base.bb:316:SUMMARY_packagegroup-base-3g<br>
> > = "Cellular data support"<br>
> > poky/meta/recipes-core/packagegroups/packagegroup-base.bb:317:RDEPENDS_packagegroup-base-3g<br>
> > = "\<br>
> > poky/meta/recipes-core/packagegroups/packagegroup-base.bb:320:RRECOMMENDS_packagegroup-base-3g<br>
> > = "\<br>
> <br>
> <br>
> <br>
> So it's actually in the same file that we already opened. Here you can<br>
> facepalm,<br>
> but we didn't know that, so this would be the procedure anyways to track it<br>
> down.<br>
> Now, search for *packagegroup-base-3g* inside the<br>
> *poky/meta/recipes-core/packagegroups/<a href="http://packagegroup-base.bb" rel="noreferrer" target="_blank">packagegroup-base.bb</a><br>
> <<a href="http://packagegroup-base.bb" rel="noreferrer" target="_blank">http://packagegroup-base.bb</a>>*<br>
> and you see this line:<br>
> <br>
> ${@bb.utils.contains("DISTRO_FEATURES", "3g", "packagegroup-base-3g", "",<br>
> > d)} \<br>
> <br>
> <br>
> Therefore the *3g* in the *DISTRO_FEATURES* actually added *ofono*. That<br>
> means that,<br>
> we need to remove the *3g* string from our *DISTRO_FEATURES*.<br>
> <br>
> To do that, add this to your build/conf/local.conf file<br>
> <br>
> DISTRO_FEATURES_remove = " 3g"<br>
> <br>
> <br>
> Now just to be sure, run this to clean *ofono* from cache and everywhere<br>
> else:<br>
> <br>
> bitbake -c cleanall ofono<br>
> <br>
> <br>
> And then rebuild the image:<br>
> <br>
> bitbake image-name<br>
> <br>
> <br>
> Now you'll see that *ofono* won't b e downloaded or get built and it won't<br>
> be in your image.<br>
> <br>
> I hope the above guide helps a bit.<br>
> <br>
> I would be glad to get better suggestions or other people experience on<br>
> how they introspect their images and solve related issues.<br>
<br>
Thanks for this useful summary of tools.<br>
<br>
I use buildhistory a lot. It contains recipe, binary package, image and SDK<br>
metadata. Many of the queries and tools you mentioned can be 'git grep'ed<br>
from buildhistory. I've added some more details to buildhistory like recipe<br>
layer name and SRC_URI which help too. DISTRO_FEATURES and their impact<br>
to packagegroups, image contents etc are currently missing, and they would<br>
be nice to have.<br>
<br>
<a href="https://www.yoctoproject.org/docs/2.7/dev-manual/dev-manual.html#maintaining-build-output-quality" rel="noreferrer" target="_blank">https://www.yoctoproject.org/docs/2.7/dev-manual/dev-manual.html#maintaining-build-output-quality</a><br>
<br>
Hope this helps,<br>
<br>
-Mikko<br>
<br>
> Regards,<br>
> Dimitris<br>
<br>
> -- <br>
> _______________________________________________<br>
> yocto mailing list<br>
> <a href="mailto:yocto@yoctoproject.org" target="_blank">yocto@yoctoproject.org</a><br>
> <a href="https://lists.yoctoproject.org/listinfo/yocto" rel="noreferrer" target="_blank">https://lists.yoctoproject.org/listinfo/yocto</a><br>
</blockquote></div>