To my way of thinking, a $ devtool modify linux should NEVER fail if it is preceded by $ bitbake -c do_cleanall linux The intended staging of the kernel into the workspace fails, saying that it cannot

upstream vendors provided me with a git repo of ALL necessary layers with the understanding that I'd clone the repo locally and disable network access, using only our local cloned repo in dl_mirror/ T

Is there not a separate list address to post patches, so as to keep discussion and patch lists separate? It can be an issue for folks who are on web mailers that make you delete messages one-at-a-time

Is there a project policy reason that all these patches are posted in the main list instead of a dev list? Isn't there a list specifically for this kind of thing, to separate questions and info sharin

Does the git add have to be done as specified above? I made changes and inside the directory where the changes occured I just did a git add -am "my message", but it didn't save my changes when I rebui

I'm not sure that the git add is relevant for all recipes though. Some of them are simply tarball sources and others are shallow git archives. Should I be confident that yocto will know the difference

I am dealing with a vendor supplied yocto release where they have setup the repos as local gitshallow or tar.xz files. I asked them to do this in accordance with our strict air-gapped build policies.

<kent.dorfman766=gmail.com@...> wrote: Worked flawlessly. Thanks!

THANKS! Will give this a try once my software raid is done resyncing. I'm replacing the mainline slip driver with a custom one that tightly binds the sl link name to the owned tty so that we know whic

What is the proper way to create a recipe to build a kernel module outside of the normal kernel tree? The kernel sources need to be expanded and configured for the typical kernel makefile line make -C

was able to modify the vendor's machine/inc file to remove the offending package. Since the whole tree is in git now, I suppose that's OK, but I do wish yocto had better tools for managing inclusions

My vendor finally realized that I needed a full yocto release and not the eSDK. Anyway, I can build their image, but when I modify the kernel to remove CAN drivers I get the errors that packagegroup-c

OK guys. I was able to make it work with a higher priority layer and a bbappend file. The difference with my config file is that mine actually defines all the CONFIG_ options but many of them are =n t

I'd prefer to not go that route. It's a modified "vendor supplied" kernel from an internal tarball source, and for IA/QA reasons we're NOT going to refer to any external GIT repos. Can someone tell me

I have a yocto generated sdk that includes a customized kernel. I do NOT want to play with incremental config files. What I want is to insert a .config file of my own choosing (generated outside of yo

Agreed. That is kind of where we are at. Yes, these closed source layers/packages simply point to closed source repos. I need them to prepare pre-compiled archives for these packages that can be overl

I think that was their intention from the start. they wanted to only give their customer the ability to produce user level apps, without modifying the system, but for our enterprise that is unrealisti

thanks for the followup! yeah...no legal advice is expected online...just a forum to vent in, sometimes. Yup...been there, done that. Yes, very bad choice in a field with no notably good choices. OK,

Oh, and this is the THIRD time I've tried posting this...you certainly don't make the yocto mailing lists easy to subscribe to. Lemme appologize in avance because parts of this are going to come acros