Okay, so in my last article I mentioned that I’d be developing a new package to add into the Linux RT and demonstrate adding recipes to do so. What we’ll need to do is:

• Create a new layer in our source directory
• Add said layer to our build
• Build a specific recipe
• Add our opkg feed to a Linux RT device
• Perform the installation

To test our package I’ll use a virtualised version of the NI Linux RT which tonight I’ll write a quick article on how to do this since I need a keyboard to do that and am currently at my support bubbles (I live on my own most of the time).

Anyway, let’s get started. Since the last article, my computer has restarted, but since it’s a cached file system which uses checksums to check if it can kick off where it left off, we can resume where we were by sourcing our original ni oe file:

. ni-oe-init-build-env

Now that we’re back in bitbake, let’s use the tool. Since we’re in the build directory and our source directory is elsewhere, unlike typical yocto instructions, we’ll need to adapt slightly:

bitbake-layers create-layer ../sources/meta-edxample

We now add this to our bblayers.conf with:

bitbake-layers add-layer ../sources/meta-edxample

Now I mentioned we’ll show pipoe in this article which I’ll do towards the end. For now, I’m going to prioritise re-using another recipe and updating cmake. I’m doing this outside of simply replacing the meta-openembedded layer as I don’t want to affect my complete build and need lots of troubleshooting, I just want to create another cmake package alongside.

First though, let’s look at our layers file structure and go to where we created it:

We need not worry about conf since this is a basic layer.conf which states what version of yocto we support and how to navigate the file structure, which is all done and working and generated by bitbake for us.

First let’s rename recipes-example to recipes-devtools. Now let’s navigate to our home directory in a second terminal and git clone dunfell openembedded.

Now let’s go to the meta/recipes-devtools and locate and copy cmake:

Paste this into our new layer and delete the recipe-example folder. Before we go and build, one final thing to do, the new cmake depends on a newer version of LibArchive so I got the error:

Googling LibArchive yocto, it has it’s own recipe and the great part is, the version is decided in the recipe name. So let’s navigate to that folder:

And we update by renaming the file to libarchive_3.5.1.bb. This works because the version it grabs from the server is based on the variable PV which is defined by bitbake as any stream of values before .bb but after the underscore in a recipe name:

When we run cmake we’ll get another error that our checksum is incorrect, it’ll nicely tell us what it should be so I just run cmake and then replace SRC_URI checksums with those values it gives. Because we’ve renamed the recipe, even though we’re asking to build cmake, it’ll recognise the update and perform that first since cmake depends on this package.

Now let’s run in our terminal of bitbake:

bitbake cmake

So here we’ll quickly get:

The error is super informative, let’s follow it’s instructions and update our recipe:

Now let’s perform a clean and rebuild:

bitbake -c clean libarchive
bitbake cmake

The next bit to fix is that during the do_patch we get several failures, this is because they’ve probably been added to the upstream and new versions so I simply removed these and iterated through build, fail, remove failing patch, build to result at here:

I then received a patch failure not in the list. Strange, so I figured this must be in a .bbappend and searched the whole sources directory to find a .bbappend in the meta-nilrt folder.

It’s only the one patch when we look:

I don’t want to delete this one without checking it out, so first let’s delete the patch from the list. We do this so that we can actually unpack and look at our source code in devtool.

And comparing our patch:

To the code:

We can see that similar to before, this patch has already been applied, hence the failure. We’ve already removed this anyway, so let’s devtool reset and build cmake again:

devtool reset libarchive
bitbake cmake

We saw the checksum issue before, a final checksum post unpack is to check the licensing. Yocto is a stickler for licensing, open source licenses are very important and should never be ignored, don’t just assume you can reuse and resell a piece of software because it’s open source. Anyway, mini rant over, here’s the error we will see plus the checksum we should replace:

Let’s go ahead and replace and then rebuild. I’ve had people mention you should do this before a build but really I find the build to be more efficient, it tells me what checksum I need without having to download it all myself and do the checksum manually.

And hey presto, we’re building a new more up to date cmake package!

The principle in this article is the how-to, even if errors happen, it’s progress usually, you can hit error after error with yocto but eventually get a build as we saw in the first article. They are not to sway you away from this and I often find people turn away at the first error which is very unfortunate, especially when usually the error message gives you exact instructions on how to repair it.

Anyway, let’s now go to our virtual machine and add our repo:

nano /etc/opkg/opkg.conf

Using this article, let’s add our feed:

https://openwrt.org/docs/guide-user/additional-software/opkg

Now on our build server in bitbake let’s update our package feed:

bitbake package-index

Now on our deployed machine run:

opkg update

Now our cmake package is available to install. But I then hit another error and learned something new, the opkg has several signature checks and in order to remove these since we haven’t generated signatures for our opkg feed you also need to remove a config file, don’t worry, if you read it, it tells you to remove it if you want to disable this.

rm -rf /etc/opkg/opkg-signing.conf

Now when we run update we get:

And now, let’s install!

opkg install cmake

As you can see, this doesn’t just install cmake but all of it’s dependencies which is quite a lot:

As a result, this is why you can’t just copy across one ipk and want to really expose the whole repository via HTTP and use opkg with a feed.

Now we’ve done this, we can see our update has been achieved:

This is a really useful update for C developers on this platform, the initial build uses an old cmake which you would want to update to support building the newest versions of most software packages and how I began finding the benefits of yocto with NI Linux.