Bit-baking with soda

If you are working with are larger stack of recipes and update them frequently, you'll inevitably reach the point where a recipe becomes obsolete. Nothing in your stack will use it, so it basically is just a burden (and a potential hypothetical security risk). I had this situation with the insane amount of npm packages I maintain for my meta-sca layer. Those change nearly on a daily basis, with new dependencies coming in and replacing old dependencies. One could read all the change logs, but lets be honest, nobody does that but just for a small chosen few recipes - so the question remains... How to I identify obsolete recipes? Simple, by looking up all the dependencies of each recipe to another in a layer - kind of obvious isn't it :-). Lucky me, I don't have to do that manually, we are programmers, we automate stuff - so I did: the result can be found in my meta-buildutils layer - a small script called unused this one can be used without setting up bitbake at all, it ju...

This post is special, in the sense that it marks an important event in my life as a software developer. But let's start from the beginning... oelint-adv When you use bitbake/YOCTO on a frequent basis, you might have are checked out my linting tool for these file called  oelint-adv . This tool parses bitbake file and checks for several rules and best practices when it comes to working within this ecosystem. Initially I thought about using the original bitbake parser , which is available as open source licensed under GPL-2.0 - Unfortunately it requires more or less a whole workspace setup, including all layers a.s.o. As this was meant as a quick check tool to be used in CI or git pre-commit hooks, I was pretty sure that this wouldn't work, so I wrote my own parser for bitbake files, till then exclusively used with the linting tool. Scancode-toolkit All of a sudden, I got a few weeks back a ticket on my GitHub repo that somebody else had more or less the same issue - they wanted t...

Have you ever considered to use python as a scripting language in an embedded system? I've been using this on recent projects although it wasn't my first choice. If I had to choose a scripting language to be used in embedded I always had a strong preference for shell/bash or lua, because they are either builtin or designed to have a significant lower footprint compared to others. Nevertheless the choice was python3 (was out of my hands to decide). When putting together the first builds using YOCTO I realized that there are two sides to python. the starting phase, where the app is initializing the execution phase, where the app just processes new data In the 2nd phase python3 has good tradeoffs between maintainability of code vs. execution speed, so there is nothing to moan about. Startup is the worst But the 1st phase where the python3-interpreter is starting is really bad. So I did some research where is might be coming from. Just to give a comparison of ...