I just wanted to mention that foss-gbg has started again after the summer break. If you’re in the vicinity of Gothenburg October 28, you are welcome to learn about open hardware and security. Get your free tickets from eventbrite.
meta-kf5 usable
Finally I’ve had the time to work over the final issues in meta-kf5. Right now, I build most tier 1 and tier 2 components. I’ve packaged most functional modules and integration modules from these tiers.
When it comes to integration modules, there might be missing dependencies that need to be added – but that should not be too hard to add.
To be able to create useable cmake files, I had to employ a small hack modifying the cmake-files from KF5 before installing and packaging them. This seems to work (i.e. tier 2 builds), but there might be other sed-expressions that are needed.
Also, the autotests are not built as long at Qt5Test is left out form the build. If you would add Qt5Test, I believe that the unit tests will be included in the same package as the libs. I’ll address this as I integrate the autotests into ptest.
Summing up all of this, I’d say that the meta-kf5 layer now is usable!
That is all for now. As always, contributions are welcome! If you find a use for this, I’d be happy to add your project as a reference to the layer!
meta-kf5 – almost there…
So, as of tonight, all but three tier 1 modules from kf5 are built in meta-kf5. The ones remaining are KApiDox, which does not really apply, and KConfig and Sonnet, which both needs to be part built for the native host environment, and part cross compiled. So, any Yocto hackers out there, please have a look at the issues linked to from the meta-kf5 status page.
meta-kf5 progress report
The meta-kf5 Yocto layer is coming along nicely. Most of the modules are proving to be fairly easy to integrate, much thanks to the excellent ground work in meta-qt5, including the cmake_qt5 bbclass.
My plan for the summer vacation was to do one module a day, so around 5 would be ok. Until now I’ve done 9. Only KConfig has been providing any resistance (it does not like QT_NO_SESSIONMANAGER). My current pipe for tier 1 modules has 6 more candidates in it, so hopefully I can say that I’ve done 15 modules tomorrow night.
Right now, I have only one big worry – I have no code using the packages, so it is a bit of a if-it-compiles-it-works mentality right now. This should be fixed by integrating the test cases from the KF5 modules with ptest and building a test image. This is something that I’ll have to look at further along the road.
KF5 in Yocto
KDE recently released the first version of KDE Frameworks 5, or shorter KF5. This is a set of add on modules extending and improving Qt, forming the base on which the Plasma Desktop is built. The nice thing is that KF5 is very modular and very reuseable.
Recently I’ve spent some time working with Yocto (yes, the series will continue – I just need time to do a couple of clean builds). So, I thought this was the perfect little summer vacation project for me. So, the plan is to package one module a day of KF5 for Yocto. The layer resides on github as meta-kf5.
This is a release early, release often project, so I’ve just gotten KAchive and ECM integrated. You can follow the progress from the project status page.
Closing comments after 14 days
Due to an increase in spam, I’ve had to disable comments for all posts older than 14 days. Sorry about this.
Introducing Grapher
I just found myself in the situation where i need to be able to create bargraphs.
The design is fairly limited: a row of stacked bars with optional labels under and inside each bar.
I also want to be able to color the bars.
I wrote a quick little PyQt-based Python program. It lets you write things like this:
bs = BarGraphStack()
bg = BarGraph()
bg.setTitle("Image Size")
bg.addBar(Bar(6349, Qt.Qt.darkGray, "6 349KiB", "kernel(bz)"))
bg.addBar(Bar(25240, Qt.Qt.lightGray, "25 240KiB", "rootfs"))
bs.addBarGraph(bg)
i = bs.render();
# i is a QImage
You can get the latest source code from the Grapher github repository. It is probably obvious that this is Python code written by a C++ guy, but I hope that it still might be useful.
Now I need to add some steps to feed it data automatically, but that is for another day.
Yocto part IV – going on a diet
This time we will start looking at how we can reduce the image size of the diet-image. Before we start, lets do a super-quick recap of the first three installments (i, ii, iii):
Start by creating and populating a project area:
mkdir minimal
cd minimal/
git clone git://git.yoctoproject.org/poky
cd poky/
git checkout -b daisy origin/daisy
source oe-init-build-env minimal-qemu
cd ..
git clone https://github.com/e8johan/meta-diet.git
cd minimal-qemu/
vim conf/local.conf
Add the following lines at the end of conf/local.conf.
DISTRO_FEATURES_append = " systemd"
VIRTUAL-RUNTIME_init_manager = "systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
VIRTUAL-RUNTIME_initscripts = ""
INHERIT += "buildhistory"
BUILDHISTORY_COMMIT = "1"
Add the meta-diet layer to BBLAYERS in conf/bblayer.conf, and build the image.
bitbake diet-image
And now, lets get back to business.
Today, I will demonstrate how to modify an existing package through a bbappend file, but first, some background.
Back in part ii, I presented a list of the packages included on the image. Something that surprised me was the inclusion of libx11-6 and libxcb. Both associated with the X windowing system which the image does not include. Using the depents.dot file, I found that the source of this dependency was the dbus package. To be more exact, this line from meta/recipes-core/dbus/dbus.inc:
PACKAGECONFIG[x11] = "--with-x --enable-x11-autolaunch,--without-x --disable-x11-autolaunch, virtual/libx11 libsm"
The nice thing about PACKAGECONFIG lines like the one above, is that they contain two halves – one to use if the feature is enabled, and one to use if the feature is disabled. So, what we need to do, is to ensure that PACKAGECONFIG does not include “x11”. I prefer to do this using a bbappend file.
A bbappend file is used to override, or append, configuration options to an existing bb file, i.e. a package recipe. At the time of writing, the d-bus package is named dbus_1.6.18.bb, so the corresponding append file is named dbus_1.6.18.bbappend. I put it in the recipes-core/dbus subdirectory, inside the meta-diet layer.
As we want to remove the dependency on X11, I create an append file with the following line:
PACKAGECONFIG_remove = "x11"
The file is available from the meta-diet layer on github. Use the tag part-iv to get the right version.
Building the image again, we can see that the libx11-6 and libxcb references are gone from the installed-package-sizes.txt build statistics file:
8637 KiB systemd
4487 KiB udev-hwdb
3042 KiB libc6
1221 KiB e2fsprogs-e2fsck
1153 KiB shadow
789 KiB dbus-1
547 KiB kmod
532 KiB busybox
398 KiB udev
349 KiB libkmod2
297 KiB libext2fs2
296 KiB libdbus-1-3
261 KiB libmount1
249 KiB udev-utils
241 KiB libblkid1
233 KiB systemd-analyze
161 KiB liblzma5
159 KiB libexpat1
110 KiB v86d
94 KiB util-linux-fsck
86 KiB libz1
83 KiB libgcc1
36 KiB systemd-binfmt
32 KiB kernel-module-uvesafb
31 KiB util-linux-mount
31 KiB libwrap0
30 KiB libacl1
29 KiB util-linux-agetty
27 KiB libe2p2
23 KiB netbase
20 KiB kernel-3.14.0-yocto-standard
16 KiB libattr1
15 KiB libcap2
14 KiB libuuid1
11 KiB kernel-module-binfmt-misc
10 KiB libcom-err2
5 KiB update-rc.d
4 KiB update-alternatives-opkg
4 KiB base-files
3 KiB busybox-udhcpc
2 KiB shadow-securetty
2 KiB run-postinsts
1 KiB systemd-serialgetty
1 KiB busybox-syslog
0 KiB systemd-compat-units
0 KiB packagegroup-core-boot
0 KiB base-passwd
Comparing this to the previous list, we just shaved off 1423 KiB. Lets call that a success for today, and we will have a good look at udev next time.
Update! Thanks Erik, for telling me about the *_remove. I only knew about *_append. Also, fixed the quotation marks in the snippet for enabling build history. Again, well spotted by Erik.
Yocto part III – a custom meta layer
In this part of the series (previous: i, ii) we will have a look at setting up our own meta layer, so that we can make changes without having to fork the Yocto recipes.
The easiest way to create a layer is to use the yocto-layer tool. To fully understand what a layer consists of, I recommend looking at the instructions for creating a layer manually as well. So, long story short:
cd ..
yocto-layer create diet
The name, meta-diet, comes from my goal with this series – to create a minimal fast booting image. Only time will tell how well that goes.
The yocto-layer create command produces an MIT-licensed layer. The MIT license is a weak copyleft, so you can choose to close it. I’ll leave it open for your enjoyment. Also, remember to change the README file. It contains a few references to xxxx and yyyy, which would be you and your project.
As we don’t want the layer to be a part of the layers provided by the Yocto project, we need to separate it out. To do this, change the directory so that you stand in the meta-diet directory and run:
git init
Now you are free to do what you like. I suggest making a commit of what is there and perhaps add a remote so that you can push your changes somewhere.
An empty layer is only so much fun, so lets start by adding a recipe for your core-image-minimal, enhanced with systemd-analyze. First, let’s create a directory for the recipe:
mkdir -p recipes-diet/images
In that directory, create the diet-image.bb file using your favorite, non-emacs, editor. Put the following code in it. This means that we use the core-image-minimal as base, and add systemd-analyze to what we want to install onto the image.
require recipes-core/images/core-image-minimal.bb
IMAGE_INSTALL += "systemd-analyze"
As copying code from a blog post is boring, I’ve put the layer on github as meta-diet. For this installment, use the part-iii tag.
To build the diet image, change directory to the build directory and edit the conf/bblayers.conf file. Simply add the new layer to the BBLAYERS variable. Now you can bitbake the new image as simple as:
bitbake diet-image
So, this installment got us nowhere feature wise, but now we have everything in place to start experimenting!
Yocto part II – baseline image size
In the first installment of this series, we established a base line image and had a look at the initial boot performance. This time, we will establish a baseline for the image size. In an embedded system, these two factors often go hand in hand, as reading data from FLASH often consumes a considerable amount of time during boot.
It is fairly easy to see how large the resulting root file system and kernel are, but we need more detail. To enable some statistics for the sizes of the various packages built, we first need to enable build history and rebuild our baseline image. Build history is enabled by adding the following lines to the local.conf file.
INHERIT += "buildhistory"
BUILDHISTORY_COMMIT = "1"
This produces a set of files with statistics in buildhistory/images/qemux86/eglibc/core-image-minimal. The files-in-image.txt file, a detailed list of all the files of the system, along with their sizes, is listed. In the installed-package-sizes.txt, we get a list of responsible packages. The list for a baseline image can be seen below.
8641 KiB systemd
4487 KiB udev-hwdb
3042 KiB libc6
1290 KiB libx11-6
1221 KiB e2fsprogs-e2fsck
1153 KiB shadow
798 KiB dbus-1
547 KiB kmod
532 KiB busybox
398 KiB udev
350 KiB libkmod2
299 KiB libdbus-1-3
297 KiB libext2fs2
261 KiB libmount1
249 KiB udev-utils
241 KiB libblkid1
233 KiB systemd-analyze
161 KiB liblzma5
159 KiB libexpat1
133 KiB libxcb1
110 KiB v86d
94 KiB util-linux-fsck
86 KiB libz1
83 KiB libgcc1
36 KiB systemd-binfmt
32 KiB kernel-module-uvesafb
31 KiB util-linux-mount
31 KiB libwrap0
30 KiB libacl1
29 KiB util-linux-agetty
27 KiB libe2p2
23 KiB netbase
20 KiB kernel-3.14.0-yocto-standard
19 KiB libxdmcp6
16 KiB libattr1
15 KiB libcap2
14 KiB libuuid1
11 KiB kernel-module-binfmt-misc
10 KiB libcom-err2
9 KiB libxau6
5 KiB update-rc.d
4 KiB update-alternatives-opkg
4 KiB base-files
3 KiB busybox-udhcpc
2 KiB shadow-securetty
2 KiB run-postinsts
1 KiB systemd-serialgetty
1 KiB busybox-syslog
0 KiB systemd-compat-units
0 KiB packagegroup-core-boot
0 KiB base-passwd
In addition to this, the bz kernel image is 6.2MiB.
My approach to this system will be that of a gadget maker, so when trying to optimize the size of the system, I will try to use as much as possible of what I know of the target hardware to minimize the size. This ought to make it possible to reduce the kernel, the udev-hwdb and more. In addition to this, Lennart says that systemd is tweakable when it comes to size. I’m looking forward to trying this.
That is all for this installment. Next time we will have a look at setting up our own meta layer to start playing with, then we will try to create a truly minimalist and fast booting image.