Bit-baking with soda

The 'a' in compliance stands for abstract things, that most developer try to avoid artificial created rules (as it's the nature of laws to be sometimes illogical;-)) an absolute must-have if you're working with open-source software. for me it additionally stand for automation potential Introducing the issue Just think of the following situation: a random guy, you never worked with before (and you don't know personally) tries to contribute a bitbake recipe for a new component. As we all know each recipe has a LICENSE entry, which offers a SPDX compatible representation of a LICENSE (or multiple licenses) applied to the source code, that the recipe offers build information for. So how can you be sure, that this setting is correct? Well you can scan the source code all by yourself and try to figure out under what license the source code is provided. For a single source repository, I guess that's  fairly easy, but time consuming. B...

What's the story? I guess most of you are familiar with the concept of merge or pull requests, so I won't go into details on these - but in case you missed it,  here is a brief description what GitLab thinks it is. There are basically two side involved into a merge request (or MR as the cool kids would say;-)) the one who actually provides the code change, lets call them devs the one who's maintaining the repository, where the change should be applied Both sides might have different objectives. The dev wants the code, she/he already wrote (hopefully tested) and streamlined, to be part of the repo upstream - as otherwise she/he could skipped all that work and enjoyed life (something we should all do from time to time). The maintainer usually lacks some implementation detail and is more keen on having the contributed code to be written according to the project style, the code being regression tested, covered by unit tests, so she/he can be sure that the fresh con...

When you're working with bitbake, especially when you're maintaining recipes, you might have asked yourself how do I know which recipes I need to update As we all read the YOCTO manual from beginning till the very end (as all good participants;-), you might be aware that you can check the `upstream` status of a package/recipe be running devtool check-upgrade-status myrecipe which returns (if there is an update available) INFO:myrecipe            0.12.8          0.12.9          None 297cb2458a96ea96d5e9d6ef38f1b7305c071f32  that means, currently you're running on version 0.12.8 and there is an update to 0.12.9 available at the defined source you're pulling your sources from. So far so easy - but wait Do I have to do that all manually, each and everytime? Automating things No, of course not. I'm using GitHub for hosting my sources, so I thought it would be quite convenient to let some ...

This time I want to write something about an issue everybody maintaining a git repo might faced already - CI. In theory every push and every pull request should have been build with all supported layer-versions... well in theory. The issue If you have a local setup it's sometimes hard to switch layer-version - I agree the usage of repo  is highly recommended here, as it simplifies such work heavily. Nevertheless you might need multiple work spaces, which all need a lot of disk space. Roughly calculated you can expect ~50GB of data per architecture/distro-combination without the usage of " rm_work "-bbclass, round about 15GB if you're using it. So if you decided to support >3 layer versions of YOCTO, it's a lot of space blocked for a lot of redundant data. Not to mention that you need to build everything now and then to get results, if your code is still working or not. Solution: CI This is where you pick a CI provider - Jenkins immediately comes in...

What it this about? I know, I know strange title for a blog post. When dealing with YOCTO you mostly spend time at a single recipe while developing (at least I do), so everything is right at one place - not a big deal. But an image consists of multiple of those packages and they should all play well together. Sometimes there are "global" component (like web server) which are used by many components at the same time. And here comes the issue. I had the pleasure of putting a nginx based web server together which was configured by a bunch of configuration files, which were produced by a lot of different packages. In theory this works quite well, as you simply just adjust where it's needed, everything else should be done by bitbake - well in theory... The issue was that in a single configuration fragment a typo existed, which didn't get noticed until the whole construction was started on the target device - I personally think this is way too late. There has t...

When using YOCTO for building your software there always comes the point where everything is woven together to something bigger - usually all your recipes are put together to an image, which can be used directly for booting an embedded device. As this is the final step, extra care should be taken when it comes to checking on security. On an recipe level you can make your component as fortified as you could imagine, if another component doesn't care about security at all, your whole concept will fall into pieces. So how do I check on security when an image is created?  What do I need check for? Are there any helpful tools around, which can support me? To answer the last question first - YES there are some very useful tools around, for instance ansible . Ansible is a very flexible, extendable batch processor, which can automate most of the administrative tasks quite convenient. The result of a YOCTO build is mostly an more or less fully featured Linux system, you can...

It's been a while since I posted something in this blog - Been busy enhancing my layer for static-code-analysis over at GitHub - But I'm back to tell you something about the baddest error of them all: the typo. Over all projects I experienced in my professional life, there were always at least one time when a bug flew in about a typo in an error message or in some documentation file. Mostly release date was near, I had spend days and hours on testing the functionality behind it and all that it was keeping it to become part of the master/product was a single typo?!?! Why didn't tell some one me that earlier? Mostly a code review was involved in the process - Had nobody seen this? The short answer: No! Everybody is going blind after looking at code for a while. So how to become aware of a typo or a badly written document as early as possible? If you have been to this blog before, you may the answer: static code analysis! In the IDE I'm using for most of my ...